Low-Level Security APIs

Low-Level Security APIs

I've often had the luxury of being able to specify to the customer the version of the operating system that my application required. For many applications you don't have that luxury, and you're stuck supporting installations on several versions of the Windows NT family. The system APIs that are available vary quite a bit with operating system version. The only API calls we had available until Windows NT 4 were what are now considered the low-level API calls. Although you need to take a lot of care when using them, I still prefer to get as close to the operating system as I can if I'm going to manipulate a security descriptor directly. For example, AddAccessAllowedAce doesn't correctly set the inheritance bits in the access control entry (ACE) header. If you build every field of the ACE by hand and then call AddAce, you'll get exactly what you set. (There is an AddAccessAllowedAceEx function, which does allow you to properly set the ACE headers, but it is limited to Windows 2000 and later.)

Numerous texts and samples demonstrate writing to the low-level security APIs, including my article at http://www.windowsitsecurity.com/Articles/Index.cfm?ArticleID=9696. If you need to use the low-level API calls, I would urge you to test your code very carefully. A step that you should consider mandatory is using the user interface to set the discretionary access control list (DACL) to what you want and then either doing an extremely detailed dump of the security descriptor or saving it in binary format in self-relative form. Then set the DACL by using your code, and compare the two. If they don't match perfectly, find out why. It is possible to create (and apply) a DACL that is full of errors to an object. Common errors include applying the ACEs in the wrong order and getting the ACE header flags wrong.