Improving Access Control for Windows 2000: A Fine-grained Approach

1. Presenter • Mohamed K. Kamara

2. Presentation Topic • Improving the Granularity of Access Control for Windows 2000 • Granularity: Relative fineness to which an access control mechanism can be adjusted

3. Authors of the Article • Michael M. Swift and Anne Hopkins – (University of Washington) • Peter Brundrett, Cliff Van Dyke, Praerit Garg, Shannon Chan, Mario Geortzel, and Gregory Jensen-worth – (Microsoft Corp)

4. Major objectives of the paper • Explains the major changes made in Windows NT as a result of its vulnerabilities, increase in the integration of applications, and databases • Presents Window NT access control list mechanism and its limitations. • Addresses access control list mechanism in Windows 2000, its fine-grain, and the trade-offs that were made in the design, compared with previous designs

5. Topics at a glance • Introduction • Access control mechanism in Windows NT • Windows 2000 Active Directory (Design) • Windows 2000 Active Directory extensions (support multi-objects and their properties) • Inheritance Control in windows 2000 • Protection from un-trusted code • Related work • Conclusion

6. a) Introduction • Windows NT 4.0 was designed with the intension to provide a secure platform that will generate support for • Security services (authentication, access control, data confidentiality, data integrity, and non-repudiation) and • Information Security (confidentiality, integrity,and availability), but due to recent • vulnerabilities (security exposure in systems) that causing several • Security breaches (interruption, interception, modification, and fabrication) Microsoft realized that there was a need for more secured operating system.

7. b) Windows NT 4.0 Access control mechanism • Windows NT - A single major access control mechanism for all system resources, e. g. files, user interface objects, and kernel objects. • If an objects requires protection, it is assigned a security descriptor • It is built around discretionary access control • Other operating systems provide access control mechanisms separate for each application

8. ACL VS ACE • ACL is a container for ACE. It may contain an arbitrary number of ACEs for different users or group of users. • ACE is used to build ACL. It determines which access rights should be granted or denied to specific security principals. Two types: • ACCESS.ALLOWED.ACEs • ACCESS.DEIED.ACEs

9. Discretionary VS Mandatory Access Control • Discretionary access control:-A design where the owner of an object has absolute access control over that object, liable to specify access rights on the object. It is the bases of access control lists technology. Both NT and 2000 support discretionary access control • Mandatory access control: – A technology where the system imposes a policy on all object accesses. NT and 2000 do not support mandatory access control

10. Assigning Access Control • Access Control List in Windows NT is assigned by copying entries from ACL on the container of an object. • For instance, when a file is created in a directory, access control entries from the ACL directory of the old file are inherited and copied on to the ACL Directory of the new file.

11. The Flags for copying entries • OBJECT.INHERIT.ACE:causes an entry to be copied from directories onto entities that are not containers. Example, files • CONTAINER.INHERIT.ACE: causes an entry to be copied onto entities that may contain other objects. Example, directories • INHERIT.ONLY.ACE: Marks entries on a directory that are not used for granting access rights to the directory, but are intended only for heritance. Once the ACE is inherited, the flag is removed. • NO.PROPAGATE.INHERIT:This flag limits the inheritance, because it removes all inheritance flags after the ACE has been copied. Consequently, NO.PROPAGATE.INHERITand CONTAINER.INHERIT.ACEwill be copied into ACL of a new directory, but not to any directory below it.

12. Limitation of Windows NT Access control • A single ACL supports and controls only sixteen different access rights, because the access masks are only sixteen bits. • Inheritance does not show the difference between an object with different access rights • ACLs cannot be propagated to a tree of objects if some of the objects have ACLs that are not inherited. • There is no mechanism for restricting the rights of a program other than disabling privileges

13. Goals for Windows 2000 Access Control • Primarily correct and eliminate the limitations of NT • Permit ACLs to control access over an arbitrary and extendable number of rights such that a single ACL can protect an entry in Active Directory with many properties. • Allow administrators to set access control at a single point in the AD and let that policy flows to all necessary objects below that point. • Secure users’ data • Prevent misbehaving programs from causing damage (support fine-grained access control)

14. c) Windows 2000 Active Directory (Design) • The Active Directory is a hierarchy - single unified view of all objects and subjects on a network. It grants the right to create and delete a specific type of object within a container. • Advantages: • It brought about faster and easier management of network resources • Presents organizations with a directory service designed for distributed computing environments. • Allows organizations to centrally manage and share information of network resources. • Acts as the central authority for network security using Kerberos protocol • It is a consolidation point for isolating, migrating, centrally managing, and reducing the number of directories that may be required in a company • Arrange data as a hierarchy of typed objects, each has a common set of data properties and behavior.

15. d) Windows 2000 Active Directory extensions • Type – Specific Access Control: Allows a small access control list to protect both objects and every property of each object separately. Why? • To protect objects in the active directory • Supports adding both new object types and new property to existing object. • To eliminate the duplication of ACL • To handle multiple ALCs on single object • Get rid of the difficulties of sharing access control, which different properties with separate ALCs had in NT • To extend the access control format to accommodate more bits on the mask • To create new access control entry format with a field that specifies • a)      The property of an object • b)     The creation and deletion of child objects in a container • c)      The type of object to which the ACE applies. • It reduces cost of protecting objects with many properties, • It Allows groups of properties to be protected with a single entry • It simplifies management because administrators can grant access to a single property set.

16. Categories of Type – Specific Access Control • Object Types in ACEs: Introducestwo new fields to each entry. • ObjectType: Identifies the scope of the access control entry. It extends the set of rights available for an object. • InheritedObjectType: Controls which types of objects inherit the ACE • Property Sets: Introduces a new access check routine “AccessCheckByTypeResultList”, which checks for access to multiple properties in a single operation. • reducing costs • Simplifies extended types • Reduces the memory and performance impacts • Simplifies Debugging of access control problems

17. Major Disadvantage of Object types in general • Increases cost for storing ACLs and performing access checks • windows 2000 NTFS

18. e)Inheritance Control in windows 2000 • Both NT and 2000 assign access control to new objects through inheritance of access control entries from the ACLs on containers. But this scheme presents two major flaws: • Can not specify the different access control lists which are inherited onto different types of objects within a container • Propagation of changes to ACLs through the tree is difficult, simply because Inheritance rules cannot be reapplied without deleting any modified ACLs in the lower level of the tree. • However, these problems were corrected in windows 2000 by letting applications annotate (Interpret) each ACE with the type of object that should inherit the ACE

19. Types of inheritance • Dynamic Inheritance:Dynamic inheritance is used to grant rights to a tree of objects.That is to say that when an access right is not granted to an object, access check is done on all the parent containers; unless the right is granted or the root is reached, the check will continues. • Static Inheritance:Allows complex access control policies to be expressed, such as specifying where certain types of objects may be created. Static Inheritance is used for two main reasons: • Indexing of the full name of each object (Complexity) • Frequent reading and writing of an object is more difficult compared to changes on ACLs • The entries on the Departments container are

20. Dynamic Inheritance The entries on the Departments container are automatically inherited to the Research container during access. Adding a new entry requires updating a single ACL. For example, the addition of a single ACE to grant Backup access Departments: Admin: read, write Backup: read Acquisitions PROTECTED Jane User: Has all accesses Research Developers: read, write

21. Dynamic Inheritance An example of reapplying inheritance. The left side represents containers in a directory service, while the right side represents the resulting ACLs after increasing the entries to the ACL on the department container. Departments Admins: read, write Backup: read Departments admins: read, write Acquisitions PROTECTED Jane User: Has all access Research Developers: read, write admin: read, write backups: read Research Developers: read, write admins: read, write Acquisitions PROTECTED Jane: User All access

22. Type-Specific Inheritance Has similar characteristics as Type-Specific access control, except that the type-specific inheritance uses the “InheritedObjectType” flag to specify the type of object that inherits the ACE

23. Type-Specific Inheritance cont. The fig. Shows that a single ACL can inherit different ACEs onto different types of objects. The ACEs on the \Research container are inherited onto different object types. \Research: Container type ACE1: inherited object type = null ACE2: inherited object type = user ACE3: inherited object type = printer \Research\Jane: User type ACE1: inherited object type = null ACE2: inherited object type = User \Research\HPLaser: printer type ACE1: inherited object type = null ACE3: inherited object type = printer

24. The semantics of inheritance • To be able to exactly determine what policies may be expressed, one needs a formal description of inheritance, based on two flags with seven distinctive rules. • BOJECT.INHERITED flag • CONTAINER.INHERIT flag

25. BOJECT.INHERITED flag • The first rule guarantees that all objects with the same type inherit the ACE, which is used for access control – INHERIT.ONLY flag is turned off • The second rule ensures that all containers inherit all OBJECT.INHERIT ACEs, but here it is not used for access control – INHERIT.ONLY is turned on

26. CONTAINER.INHERIT flag • The third rule says that ACEs with CONTAINER_INHERIT flag are inherited to all containers and only those with the same type use it for access control. • Rule four extends that the ACE is marked as INHERIT_ONLY on other containers. • Rule five says that if two ACEs are ordered on a container and both are inherited to either a child object or a container, then they must be in the same order in both ACLs • Rule six stresses that if one container is an ancestor of another container, then the ancestor’s ACEs will appear latter in any ACL that inherits from both containers, but this can be eliminated if the containers are organized as a hierarchy, such that no container possesses more than one parent. • Rule seven limits the scope of the other rules for objects and containers. It ensures that none of the ACEs in protected ACL are protected.

27. How Static and Type-Specific inheritance can be combined to express complex policies. The mechanism permits administrators to instruct where certain objects can or cannot be created ACL Revision version 2 ACL Size 400 byte ACE Count 4 ACE1 (depends on rule 1 for inheritance) Type ACCESS_ALLOWED_OBJECT_ACE Access Rights write Principal SID PRINCIPAL_SELF Inherited Object Type {GUID for User Account Object} Object Type {GUID for WWW Homepage} ACE2 (depends on Rule 4 for container inheritance) Type ACCESS_ALLOWED_OBJECT_ACE Access Rights create child Principal SID Several Applications Inherited Object Type {GUID for RPC Services} Object Type {GUID for RPC Endpoint} ACE3 (depends on Rule 5) Type ACCESS_ALLOWED_OBJECT_ACE Access Rights create child Principal SID Administrator Inherited Object Type {GUID for Organization Units} Object Type {GUID for User Account Object} ACE4 (depends on Rule 5) Type ACCESS_DENY_OBJECT_ACE Access Rights create child Principal SID everyone Inherited Object Type NULL Object Type {GUID for User Account Object}

28. f) Protection from un-trusted code • Debated on method to be used to do this • Thought of augmenting Windows 2000 with more checks on the parameters of system calls. • But Windows 2000 already has enough system calls that are protecting all internal objects using Access Control List and privilege mechanisms • So introducing more system calls and try to verify those calls would cause system performance difficulties. •  Introduced the idea of restricted contexts

29. Restricted contexts • A process of restricting token mechanism where by access rights of programs are limited • Based on three goals 1)Un-trusted code should have no greater access to resources than the user running the code (least privilege) • 2)      Users should be able to restrict programs to accessing specific objects or classes of objects 3) No separate security model beyond the operating system’s protection and access control model should be needed for restricting code.

30. Recommendations • a)Use operating systems protection mechanisms by running in a separate process and address space of its own access token • b)  Access control on objects should limit the code to a subset of the objects that the user can access (least privilege)

31. What does restricted contexts do? • 1)Implement a second access check after authentication and authorization (after the user is granted access to the resources), checking also the permissions or privileges of the running program. • 2)  Can be applied across network connections for using network resources • 3)  Can be implemented to other functions such as authority delegation between mutually trusted applications.

32. Applying Restrictions to Operating System Resources • Implement tough measures of security policies • Ensure that Users neither control many internal objects no do they have permission to modify the ACLs on those objects • Ensure that the operating system creates the ACL on many non-persistent objects at boot time, so that users do not have chance to store a new ACL on those objects • The access rights for an operating system resources may be at the wrong granularity, e.g. network socket, which can not differentiate between different endpoints

33. Remote Authentication with Restricted Contexts • In this scheme, Authentication protocol can include the restrictions in the authentication messages so that they are carried to remote servers. • Windows 2000 uses the Kerberos authentication protocol with the authorization.data field to limit the client’s authority on the server. • When a restricted context tries to authenticate, the Kerberos code captures the context’s restrictions and stores them in the authorization.data field of a ticket. If this ticket is received by a server, the restrictions are applied to the access token before the server application is permitted to impersonate the client.

34. Limited delegation with restricted context • Limited delegation is the ability of an application to impersonate a client by restricting its own rights with the client’s rights. It is used to applications that trust each other Basic authentication User: Jane User Groups: developers Kerberos authentication User: web server Groups: trusted services Database Restrictions: Jane User, developers Web Server Client Application Database ACL ACE1: Access Right: all access Principal SID: web serv ACE2: Access Right: read Principal SID: user

35. Advantages of restricted context • Permits the use of a different authentication protocol between the client and the web server than the web server and the database • Permits client identities to be forwarded between trusted servers without authentication protocol support for delegation, and without allowing the server to amplify their rights to those of the client and access resources unrelated to the application. • Help users limits their rights, so they do not need run all programs with the same right. • Increases network utilities, because applications can be run in restricted context instead of having to access network services • Provides safety from un-trusted code and protects user data from attacks. • Presents a simple and understandable user interface. • Good for expressing many security policies

36. Disadvantages of restricted context • The correct context for a process executing code from multiple sources has not been determined. • The user interface for ACL editing is problematic, e.g. translating SIDs into names in the case when users may fabricate SIDs for restrictions and place them on ACLs

37. g) Related work • Realistically, the problems faced and the changes made in windows 2000, though in a different combination, have also been addressed by previous systems. • Other directory services that support fine-grained access control, and inheritance of ACLs have also been addressed in many settings ranging from object-oriented databases to distributed systems. • Restricted context has also been addressed by several operating systems

38. Novell Directory Service (NDS) VS Windows 2000 Directory Service (AD) • The access control model in Novell’s directory service, in many respects, resembles windows 2000 model because both operating systems though render some logical and physical differences, have similar application domain Windows 2000 Directory Service Model • Supports Inheritance of access rights • Does not support protection of individual properties • Supports propagation of rights to individual objects • Support grouping properties into property set • Support the inheritance of rights for specific properties • Does not support only rights for all properties at once may be inherited • Does not filter, blocks all inheritance Novell Netware Directory Service Model • Supports inheritance of access rights • Supports protection of individual properties • Supports dynamic inheritance • Does not support grouping properties into property set • Does not support the inheritance of rights for specific properties • Supports only rights for all properties at once may be inherited • Flexible inherited filters, because it blocks the inheritance of specific rights, e.g. read all properties

39. h) Conclusion Seven built in security functions • Security audit • Identification and authentication • Security management • User data protection • Protection of security functions • Resource utilization • Session locking