MSDN Magazine - November 2008 - (Page 66)

Figure 11 Integrity Labels Hex 0x0000 0x1000 0x2000 0x3000 0x4000 0x1 token n/a lW Me HI sI nW Description Untrusted mandatory level low mandatory level Medium mandatory level High mandatory level system mandatory level noWriteUp The default policy on all object mandatory labels. The policy restricts write access to the object by a subject with a lower integrity level. noreadUp Restricts read access to the object by a subject with a lower integrity level. The policy is used, for example, to restrict read access to the virtual memory address space of a process. noexecuteUp Restricts execute access to the object by a subject with a lower integrity level. The policy is used, for example, to restrict launch activation permissions on a COM class by lower integrity subjects. low and allows List, Read, ReadEA, Traverse, Execute, ReadAttr, ReadControl, and Sync. The second string_ace allows AddSubDir in the root and below (due to the IO—inherit-only flag), while the third string_ace allows AddFile in the directories below the root. This is the same as you saw when you explored these permissions with the ACL graphical interface of Windows Explorer. Windows Resource Protection 0x2 nr 0x4 nX security on the object. This creates a problem if a user is a member of a group and creates a large number of objects. If that user leaves the group, he would still have control over those objects because he is the owner of these objects, which granted them RC plus Write_ DAC permissions. The presence of the OW owner ACE restriction blocks the implicit grant of RC/WD to the owner unless these grants are explicitly made to the owner ACE of any other relevant ACE in the ACL. This allows mitigation of this security issue. Starting with Windows Server 2008 and Windows Vista, components declare their needed security settings in their manifests, which are signed by a Microsoft code signing root. The manifest specifies the ACLs and other permissions associated with the file. Thus, when a component is installed, it carries with it the appropriate security settings. In addition, OS files are protected from inadvertent damage by the system administrator using Windows Resource Protection (WRP). WRP relies upon a new system-level entity, Trusted Installer, to own and manage system files and folders. A good facility to allow normal users to perform installations of authorized components was added in Windows Vista. Thus the Power User role is no longer required, and instances of ACEs that contain the Power User SID were removed. The Power User group still exists, but the component manifests have been scanned, and all detected instances of grants to PU have been deleted. Let’s look at a system directory to see the new permissions. This is also another good exercise in SDDL reading: C:\>cacls c:\windows /s C:\Windows "D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-18310 38044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3 418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY) (A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU) (A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)" Interpreting Security Descriptor string_aces "D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU) (A;CI;LC;;;BU)(A;CIIO;DC;;;BU) (A;OICIIO;GA;;;CO)" The output from cacls for the root of the system drive was: Trusted Installer’s SID is S-1-5-80-956008885-34185226491831038044-1853292631-2271478464. Using TI as shorthand, we find the following: C:\Windows "D:PAI (A;;FA;;;TI)(A;CIIO;GA;;;TI) (A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY) (A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA) (A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU) (A;OICIIO;GA;;;CO)" Parsing this for readability, you get: "D:PAI (A;OICI;FA;;;SY) (A;OICI;FA;;;BA) (A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU) (A;OICIIO;GA;;;CO)" This is a protected DACL with the auto-inherit flag for a modern file systems set. The protected flag means that inheritable parent grants won’t be inherited; the DACL is protected from inheritance from the object’s parent. In this case there is no parent, as it is the root. The built-in administrator and system are granted inheritable File All over both files (due to the object inherit) and directories (due to the container inherit, or CI). This means that this DACL grants File All recursively on all files and directories below the root—except where inheritance is stopped by a protected DACL when the grant in the protected DACL must be examined. CO is granted Generic_All, which maps to File All, over both files and directories below the root directory (due to the inherit-only flag). The grant to the built-in user is far more interesting. The first string_ace applies to both files and directories in the root and be66 msdn magazine Interpreting this, you see it is a protected ACE that is being applied to C:\Windows using the Windows NT 5.0 inheritance model. Trusted Installer is granted full control over C:\Windows and is granted Generic_All over all child containers under C:\Windows (since it is CI, inherit only). System and admin are granted Read, Write, Append, ReadEA, WriteEA, Execute, ReadAttr, WriteAttr, Del, RCtl, and Sync, = SDGRGWGX on C:\Windows. This is Generic_All minus Write_ Owner and Write_DAC; Admin and System are granted everything but the ability to change the owner or the ACL. “BA” and “SY” have Generic_All over child file and directory objects. Since the admin has the take ownership privilege, he can still assert WriteOwnership and take control anyway. Administrator and system are a security equivalent. But with this privilege, a determined administrator can circumvent the WRP ACL controls. CO also has Generic_All over child file and directory objects. File and Registry Permissions

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.