Security objects
Windows NT's security is based on just five security objects which are used to identify and subclass users, indicate permissable operations, and relate ownership and permissions to system objects. The security objects are:- The Security Identifier (SID)
- The Access Control Entry (ACE)
- The Access Control List (ACL)
- The Security Descriptor
- The Access Token
The Security Identifier
The most basic security object in Windows NT is the security identifier, or SID. An SID is a unique identifier used to identify a user or group of users that exist on a particular computer or in a particular domain (group of computers):Account |
Domain |
NT provides two API calls that can be used to map between SIDs and user and group names. They are:
Function | Description |
LookupAccountName() | Given an account name, find its SID. |
LookupSidAccount() | Given an SID, find the account name and its domain. |
The Access Control Entry
An Access Control Entry, or ACE, is the most basic unit of permission in NT. ACEs come in two types, access allowed and access denied, which are used to grant or refuse access respectively(1).An ACE contains an SID which indicates which user or group of users the permission applies to, and a permission mask that indicates exactly what kind of permission is being granted or refused.
Type |
Security Identifier |
Permissions Mask |
The permission mask is broken into parts which indicate permissions specific to a particular object type (called specific rights) and generic permissions (generic rights) that apply to all objects.
The standard rights, which control the accessibility and exclusivity for all objects, are:
Right | Description |
DELETE | The ability to delete the object. |
READ_CONTROL | The ability to inspect the object's security information. |
WRITE_DAC | The ability to change the object's list of permissions. |
WRITE_OWNER | The ability to change the owner of the object |
SYNCHRONIZE | Force mutual-exclusion of object accesses. |
While each object type has its own list of specific rights, the filesystem rights are the most frequently encountered. They are:
Right | Description |
FILE_READ_DATA | The ability to read the file. |
FILE_LIST_DIRECTORY | The ability to list the contents of a directory. |
FILE_WRITE_DATA | The ability to modify the file's data. |
FILE_ADD_FILE | The ability to add a new file to a directory. |
FILE_APPEND_DATA | The ability to append data to a file. |
FILE_ADD_SUBDIRECTORY | The ability to add a subdirectory to a directory. |
FILE_READ_EA | The ability to read the extended attributes(2) of a file. |
FILE_WRITE_EA | The ability to change the extended attributes of a file. |
FILE_EXECUTE | The ability to run an executable. |
FILE_TRAVERSE | The ability to open a file or run an executable within a directory. |
FILE_DELETE_CHILD | The ability to delete a file or directory within a directory. |
FILE_READ_ATTRIBUTES | The ability to read a file's attributes (e.g. system or hidden). |
FILE_WRITE_ATTRIBUTES | The ability to change a file's attributes. |
The Access Control List
While an ACE is the basic unit of permission on NT, a single ACE is seldom enough to fully describe the accessibility of an object to different users or groups on the system.Consider, for example, a source code file. You need to be able to manipulate your source files in any way you like -- read them, modify them, delete them, etc. You would also like the members in your development group to be able to look at your source files, but not to change them since everyone else in your group is an incompetant dweeb who can barely understand your code, much less change it in any useful way. Lastly, you would like to keep your manager from even looking at your code lest he find out that you spent last week playing DOOM rather than working.
To maintain multiple privilege levels for different users or groups of users in this way, ACEs are grouped into Access Control Lists, or ACLs. Simply put, an ACL describes all of the users and groups who are either allowed or denied some sort of access to a particular object.
ACE |
ACE |
ACE |
... |
When a thread requests access to an object (by opening a file, for instance), the system performs two passes over the ACL.
In the first pass the system inspects every "access denied" ACE in the list. If it finds an SID that matches the thread's SID, or an SID of a group that the thread's owner is a member of, access is immediately denied.
Once all "access denied" ACEs have been inspected the system proceeds to check all "access allowed" ACEs. For each matching ACE, the permission mask in the ACE is added to a growing list of permissions granted to the thread's SID for access to the object. Once the list of permissions matches or exceeds the group of permissions that was requested permission is granted. If the end of the ACL is reached before enough permissions are accumulated access is denied.
NT provides a number of functions for managing ACLs:
Function | Description |
AddAce() | Add a new ACE to the access control list. |
DeleteACE() | Remove an ACE from the access control list. |
InitializeAcl() | Create a new ACL structure. |
IsValidAcl() | Determine validity of an ACL structure. |
GetAclInformation() | Retrieve information about the ACL. |
SetAclInformation() | Set the ACL revision information. |
Even with these functions the variable-length nature inherent in ACLs makes them tedious to deal with.
The Security Descriptor
While an ACL describes the accessibility of an object, it does not completely describe the security attributes of an object. The complete group of security attributes is kept in an object called a security descriptor, which contains:Object | Description |
The owner SID | The SID of the user who owns this object |
The object's primary group SID | The group of users to which this object belongs |
The system ACL | The access control list used for auditing features |
The discretionary ACL | The access control list that specifies which users or groups may access an object. |
When you want to view or change the security attributes of an object, you must do so through the object's security descriptor.
The following functions are used to manage the security descriptor:
Function | Description |
IsValidSecurityDescriptor() | Determine the validity of a security descriptor |
InitializeSecurityDescriptor() | Create a new security descriptor |
GetSecurityDescriptorControl() | Retrieve control information about the security descriptor |
GetSecurityDescriptorDacl() | Retrieve the security descriptor's discretionary ACL |
SetSecurityDescriptorDacl() | Change the security descriptor's discretionary ACL |
GetSecurityDescriptorGroup() | Retrieve the security descriptor's primary group |
SetSecurityDescriptorGroup() | Change the security descriptor's primary group |
GetSecurityDescriptorOwner() | Retrieve the owner from the security descriptor |
SetSecurityDescriptorOwner() | Change the owner in the security descriptor |
GetSecurityDescriptorSacl(); | Retrieve the security descriptor's system ACL |
SetSecurityDescriptorSacl(); | Change the security descriptor's system ACL |
The Access Token
An access token is essentially NT's identification card for a user. Every process, and potentially every thread, has a related access token which identifies the user account that the process is running under and a lot of default values to be used when creating new objects.An access token contains a lot of security information about the user, including their SID, their primary group SID, their current privilege set, the SIDs that should be used to indicate the owner and group of new objects and files, and the default discretionary ACL used when creating new objects and files.
Access tokens are created through login services (e.g. the login dialog or a network share login), through impersonation (temporary assumption of a user's security attributes by a service's thread), or through the NT login API (3),(4).
--------------
(1) Actually there are two more ACE types: system audit, used for generating logs of accesses; and system alarm, which is not yet implemented.
(2) As with the Macintosh, NTFS provides multiple data streams in each file which are useful for storing additional file information such as icons. Extended attributes refers to all of the data streams except for the default (normal file data) stream.
(3) This API was not publicly available prior to NT 3.51.
(4) Since the access token API is new, and is not yet on my system, no class is provided for managing access tokens.
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
ليست هناك تعليقات:
إرسال تعليق