OSRLogo
OSRLogoOSRLogoOSRLogo x Seminar Ad
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Tue, 20 Nov 2018     118021 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Security During Create Operations

Recently, someone asked us about how security was assigned to new files by the file system. Of course, this only applies to NTFS because it is the only native Windows file system that actually supports security descriptors on individual files and directories.  Presumably, this is also how other third party file systems handle security as well.

One important note: the details of how security is implemented varies by the specific version of Windows that implements the security.  For example, the NTFS driver included in more recent versions of Windows uses a different mechanism for storing individual security descriptors than earlier versions (the goal being to minimize the number of copies that are present on disk).

When a new file or directory is created - using IRP_MJ_CREATE - the file system uses the security descriptor from the containing directory as well as the security descriptor passed in by the calling application.  The application provided security descriptor arrives in the ACCESS_STATE structure, embedded within the Create Parameters field of the I/O Stack Location: IoStackLocation->Parameters.Create.SecurityContext->AccessState->SecurityDescriptor.  These two security descriptors are passed into SeAssignSecurity (note that none of the file systems appear to use SeAssignSecurityEx at the present time), along with the security credentials of the caller (the SubjectSecurityContext) and the standard generic rights mapping (IoGetFileObjectGenericMapping) used for files, as well as an indicator of whether or not the new object is a directory.

This function (SeAssignSecurity) returns a new security descriptor (allocated from pool) to the file system. From the file system perspective, this is ideal because there is no need to "understand" the details of how security descriptors are constructed - this is entirely up to the OS.  If the application does not provide a new security descriptor, presumably the container descriptor is used and those various inheritance properties are interpreted as appropriate.

Typically, the underlying file system will store the security descriptor in a compact form.  For example, it is common for there to be only a single copy of each unique security descriptor because most files and directories will use the same one or two descriptors.  Thus, this minimizes the storage overhead associated.  Of course, there is nothing that requires this implementation.

Once the security descriptor has been established, it is subsequently fetched and stored using the IRP_MJ_QUERY_SECURITY and IRP_MJ_SET_SECURITY operations.  Filters interested in security must thus observe these two operations as well as IRP_MJ_CREATE in order to watch how security is managed and manipulated.

Related Articles
Keeping Secrets - Windows Security (Part III)
Keeping Secrets - Windows NT Security (Part II)
Keeping Secrets - Windows NT Security (Part I)
You've Gotta Use Protection -- Inside Driver & Device Security
Still Feeling Insecure? - IoCreateDeviceSecure( ) for Windows 2K/XP/.NET
Securing Device Interfaces - A Better Approach than Sending an SD
Locking Down Drivers - A Survey of Techniques
What is Coming with Vista - Limited User Access

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.
bottom nav links