Lock Down Your Files (Continued)

The final piece of the puzzle is the Security Identifier (SID). An ACE uses an SID to identify an account. SIDs can also describe the owner of an object. Internally, a SID is nothing more than a binary representation of a Windows user account or a group. It is also possible to represents SIDs as strings, which gives you an easy way to transfer SID data from system to another or store data for later use.

That’s all the background you need to take advantage of the System.Security.AccessControl namespace from your .NET 2.0 applications. I want to keep things simple, so topics such as impersonation, ACE accumulation, inheritance, and empty/null DACLs are beyond the scope of this article. Again, refer to the Win32 API SDK documentation for more information if you run into topics not covered in this article specifically.

The System.Security.AccessControl namespace contains more than 70 classes and enumerations that can help you build solutions when programming against an access control. The .NET Framework 2.0 also extends many classes you might already use from earlier versions of .NET. For example, the System.IO.File class now includes methods such as GetAccessControl and SetAccessControl to get and set access control entries. The earlier .NET versions also included the System.Security.Principal namespace, which you need when manipulating SIDs.

.NET is fully object oriented, so it makes sense to have a class to correspond to each of the different players in the access control game. However, doing this is not a simple task because each of the securable object types (files, registry keys, and so on) require different methods and properties. This leads to a somewhat complex design. The AccessControl namespace attempts to minimize this complexity by making heavy use of inheritance. You should pay particular attention to the inheritance hierarchies when you study the classes in the AccessControl namespace.

Build an Access Control App
You’re now ready to begin building an app using the System.Security.AccessControl namespace (see Figure 2). The sample app doesn’t demonstrate every class available in the namespace, but does illustrate how to use the most significant ones.

When you build security apps, it’s important to know who is running the application. You can determine the user name by using the static GetCurrent method of the System.Security.Principal.WindowsIdentity class:

System.Security.Principal. _
   WindowsIdentity self = _
   System.Security.Principal. _
   WindowsIdentity.GetCurrent();
System.Security.Principal. _
   SecurityIdentifier selfSID =
   self.User;

If you have an instance of the WindowsIdentity class, you can set its User property to return an instance of the SecurityIdentifier class, also part of the System.Security.Principal namespace. Both the SecurityIdentifier class and the User property of the WindowsIdentity class are new features in .NET 2.0.

The SecurityIdentifier class is an SID. It inherits from the abstract IdentityReference class (also in the System.Security.Principal namespace). The SecurityIdentifier class includes a convenient Value property that returns the string representation of the associated identifier. You can see such a string representation under the current user name in the example application.

Note that file-based security is available only on NTFS formatted drives. This means that you can’t associate security settings with your files on Windows XP if you use a FAT32 partition. In code, it is easy to use the System.IO.DriveInfo class and its DriveFormat property to check if a drive is formatted as NTFS or not.

DriveInfo[] infos = _
   DriveInfo.GetDrives();

foreach (DriveInfo info in infos)
{

   if ((info.Name == “C:\\”) && _
   (info.DriveFormat == “NTFS”))
   {

     // drive is NTFS!

   }
}

The next step is to enumerate the ACE entries of a file (see Listing 1). Clicking on the Show Rights button in the sample application calls the custom ShowFileRights method. This method calls the static GetAccessControl method of the System.IO.File class, returning an object of type System.Security.AccessControl.FileSecurity, which is both the discretionary ACL and the system (audit) ACL of the selected file.