|
Lock Down Your Files
A single, large barrier is not as good as multiple layers of security when you want to build secure apps. Improve your security by taking advantage of file access control with the .NET Framework 2.0's System.Security.AccessControl namespace.
by Jani Järvinen
January 27, 2006
Technology Toolbox: C#, .NET 2.0, Windows 2000, XP, or Server 2003
Security is a ubiquitous part of any computer system of any size. A single large barrier is less effective than implementing multiple layers of security when it comes to creating secure applications. Fortunately, building such security layers isn’t difficult; adding security at different application levels simply requires that you approach the problem with some foresight. I’ll explain how to approach solving that problem using the .NET Framework 2.0 and its new security-related namespace, System.Security.AccessControl.
This namespace gives you low-level access to many Windows functions, enabling you to manipulate Windows Access Control Lists (ACLs) and associate them with different object types in the operating system. For example, you can now associate files, registry keys, and mutexes with an access control list. This is important when you want to build applications that implement robust levels of security.
Contrast this to the .NET Framework 1.0 and 1.1, where security-related classes in the Framework Class Library (FCL) were related primarily to Code Access Security (CAS), cryptography, or security in ASP.NET Web applications. These features are useful, but they represent only a small part of all the security features Windows makes available. For example, you might have missed the lower-level security classes to manipulate kernel object permissions, file access control lists, and so on. The initial implementations of the .NET Framework required that you call the Windows API functions directly using Platform Invoke (P/Invoke) .
Before diving into the specifics of how to manipulate access-control list functions from your applications, it might be helpful to take a close look at the features that Windows includes natively, as well as how they work and what some of their limitations are. The .NET Framework relies on the core functionality of the Windows systems it runs on to implement access-control lists.
Windows operating systems build access control directly into the NT-based operating system family, which includes Windows NT, Windows 2000, Windows XP, and Window Server 2003. Unfortunately, the Windows 95/98/Me versions don’t support access-control lists, which means that the .NET classes related to access control won’t work, because they rely on the innate features of the operating system. You can’t take advantage of what isn’t there.
Access control lets you provide security for different types of objects known as securable objects. Such objects include (but are not limited to): files and directories on NTFS formatted drives; Registry keys; Windows services; printers; network shares; Win32 event objects, mutexes and semaphores; Active Directory objects; and processes and threads. Windows can associate a security descriptor (SD) with each of these object types (see Figure 1) .
Inside the Security Descriptor
A security descriptor is an important concept in Windows security. It contains the owner of the object, a discretionary access control list (DACL), and a system access-control list (SACL). It’s easy to confuse these different terms when learning about access-control programming, so I’ll provide you with a quick run-down of these key terms and summarize how they are pertinent to the using access-control lists from .NET. Note that you can always turn to the Win32 API SDK documentation if you have additional questions my own short descriptions don’t cover.
The DACL contains one or more entries that control how you can access the object that contains the ACL. A SACL contains one or more entries that control event logging when the object is accessed. The DACL and SACL are examples of Access Control Lists (ACLs). ACLs can contain one or more items called Access Control (ACE).
The work that an ACE can control depends on the object type, but common types of actions include reading, writing, and deleting objects. An ACE can either allow or deny such work. DACLs fall into one of two categories: an access-denied ACE or an access-allowed ACE.
Back to top
|