MSDN Magazine - November 2008 - (Page 59)

Access control Understanding Windows File And Registry Permissions John r. Michener Whenever something happens in a system, a principal (which could be a process or thread acting on behalf of a user or service) acts upon objects. Files, directories, and registry keys are examples of commonly known objects. The basic security mechanism of Windows involves having a trusted system component check permissions and rights (AccessCheck) before an operation is allowed to proceed. Thus, you manage system behavior by setting permissions and rights. Since you cannot appropriately set permissions without understanding what is being done under the surface, I’ll start by describing security settings on objects and how they are processed, and I’ll follow that with how to set values for them. Before I delve into the technical details, I want to take a look at the permissions at the root of the system drive in Windows Server 2008 using the Windows access control list (ACL) GUI. If I open Windows Explorer, select the security tab, right-click on Local Disc (C:), and select Properties, I see that administrators have full control. If I click on SYSTEM under Group or user names, I see that SYSTEM also has full control. When I click on Users under Group or user names, I see that the permission situation is not as simple: the users group on the system in Figure 1 has Read and Execute, List, Read, and so on. Clicking the Advanced button gives a more detailed view of the permissions associated with the users group (see Figure 2). Here, members of the users group are allowed to create folders and append data to files in the root of the system drive. If you click the Edit button, you’ll see another “special” grant to subfolders, shown in Figure 3. This operation requires administrator privileges. Thus you see that normal users are allowed, by default, to create subfolders and add content to these folders from the root of the system drive in Windows Server 2008. This functionality was provided to members of the users group on Windows Server 2008 because some third-party software assumes that these permissions are present, and Microsoft did not want to break app compatibility. Now let’s move to a technical discussion of these issues and how they work below the GUI interface presented to the user. All named objects in Windows have security descriptors, which provide information about their owner as well as list which users and subjects have specified permissions. They also can specify which object accesses must be logged to the system event log. The information about what a subject (user, process, and so on) this article discusses: • Access control lists • User rights • File system permissions • registry and its permissions technologies discussed: Windows server 2008 November 2008 59

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.