|
|
1.1 root 1: Sample: Demonstration of Code to Examine SD's (Security Descriptors)
2:
3: Summary: In the Win32 .hlp file, if you click on Search, goto
4: "Security Overview", then choose from the list of topics under
5: Security Overview the sub-topic "Allowing Access", you'll find
6: the comment
7:
8: Note: It is fine to write code like this that builds security
9: descriptors from scratch. It is, however, a good practice
10: for people who write code that builds or manipulates
11: security descriptors to first write code that explores the
12: default security descriptors that Windows NT places on
13: objects. For example, if Windows NT by default includes in
14: a DACL an ACE granting the Local Logon SID certain access,
15: it's good to know that, so that a decision not to grant any
16: access to the Local Logon SID would be a conscious decision
17:
18: Purpose of this sample: The comment in the .hlp file is accurate,
19: however, for many people this task of examining the SD is easier
20: if there is sample code to start from. So, the purpose of this
21: sample is to assist people by providing sample code people can
22: start from as they examine SD(s). This sample as is examines
23: the SD on files, and this code can be modified to examine the SD
24: on other objects
25:
26: This sample is not a supported utility
27:
28: To run: Type Check_sd to check the SD on the \\.\A: device
29:
30: Type Check_sd d:\a.fil to check the SD on the d:\a.fil
31: file. In this case d: must be formatted NTFS,
32: because only NTFS files have SD(s)
33:
34: Further notes:
35:
36: - If you recompile with this define set like this
37:
38: #define I_DO_NOT_WANT_THIS_CODE_TO_CLUTTER_THIS_PROGRAM_S_OUTPUT (1==0)
39:
40: and re-run the program, the program will produce a lot more
41: output, including displaying all the info you can access in
42: a Win32 program from the process's Access Token, and the
43: SD's of some sample objects
44:
45: - If you logon, run with the program built to produce the extra
46: output as mentioned just above, save that output to a file,
47: then log off and re-run the program, save the output of this
48: second run to a different file, you can with WinDiff easily
49: observe how the local logon SID really does change values for
50: each logged on session
51:
52: - A sample test you could run to exercise DACLs involves using the
53: \q_a\samples\sd_flppy sample in conjunction with this check_sd
54: sample
55:
56: - Log on to a machine as a local Administrator
57: - Do
58: check_sd \\.\A: >out_bef.a
59: check_sd \\.\B: >out_bef.b
60: - Logoff
61: - Log on the same machine as Guest on the local machine domain
62: - Do
63: sd_flppy
64: - Try
65: dir a: (observe access denied)
66: dir b: (observe access denied)
67: copy config.sys a:\ (get device not found)
68: copy config.sys b:\ (get device not found)
69: - Logoff
70: - Log on the same machine as a local Administrator
71: - Do
72: check_sd \\.\A: >out_aft.a
73: check_sd \\.\B: >out_aft.b
74: - Browse the differences between out_bef.* and out_aft.*
75:
76: - The above sample test demonstrates that the ACLs that sd_flppy
77: applies survive logoffs. To demonstrate the DACLs do not
78: survive rebooting, simply reboot, log back on as a local
79: Administrator, and
80: check_sd \\.\A: >out_rbt.a
81: check_sd \\.\B: >out_rbt.b
82: to see the DACLs are again as they were in
83: out_bef.a
84: out_bef.b
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.