Presenter
•
Mohamed K. Kamara
Presentation Topic
• Improving the Granularity of Access
Control for Windows 2000
• Granularity:
Relative fineness to which an access
control mechanism can be adjusted
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)
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
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
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.
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
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
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
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.
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.INHERIT and CONTAINER.INHERIT.ACE will be copied into ACL
of a new directory, but not to any directory below it.
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
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)
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.
•
•
•
•
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
•
•
•
•
•
•
•
•
Categories of Type – Specific Access
Control
•
Object Types in ACEs: Introduces two new fields to each entry.
1)
2)
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
1)
2)
3)
4)
“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
Major Disadvantage of Object types in
general
•
Increases cost for storing ACLs and
performing access checks
•
windows 2000 NTFS
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
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
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
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
admins:
read, write
Acquisitions
PROTECTED
Jane: User
All access
Research
Developers:
read, write
admin:
read, write
backups:
read
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
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
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
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
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.
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
ACL Size
ACE Count
version 2
400 byte
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}
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
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.
Recommendations
•
Use operating systems protection mechanisms by
running in a separate process and address space of its own
access token
a)
• b) Access control on objects should limit the code to a
subset of the objects that the user can access (least
privilege)
What does restricted contexts do?
•
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.
1)
• 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.
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 nonpersistent 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
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.
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
Web Server
Client Application
Database
ACL
ACE1:
Access Right: all access
Principal SID: web serv
ACE2:
Access Right: read
Principal SID: user
Kerberos authentication
User: web server
Groups: trusted services
Database
Restrictions: Jane User, developers
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
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
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
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
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