الأحد، 26 أبريل 2009

Security objects

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
Each of these objects builds upon the others in order to provide certain security features.

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):
Security Identifier
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.
Access Control Entry
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.
Access Control List
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!

ليست هناك تعليقات: