Windows NT internally and automatically handles the storage and checking of security settings only on its own Kernel system objects; any other objects you define and create are not protected automatically. If you need to enforce security on your objects, you must implement this security yourself.
To add access restrictions (security) for anything not covered by NT’s built-in/automatic security, you need to specify the desired permissions and then check those permissions every time an attempt is made to access your object. NT’s security API gives you some help in accomplishing this; its set of functions are identical to the functions used by NT’s own internal security. Therefore, the process you go through to secure your own objects has much in common with what NT does to provide security for its objects.
The distinction between NT’s built-in security and application security is not absolute. If you’re creating some object that, in turn, makes use of one or more system objects, NT may automatically provide some level of security for these system objects. If you store your object in a file, for example, that file will be subject to NT’s built-in file security just like any other file (if it’s located on an NTFS partition, that is).
This overlap of NT’s system security with additional security that you may implement is not only welcome, but is essential to the proper implementation of security in your application. For example, NT itself knows how to restrict access to files, subdirectories, and drives. But, as an example, it doesn’t know anything about the fact that part of your database file contains data that should be available to only certain users, while other parts may be appropriate for general access. In this particular case, you would need to protect your database file in two ways. First, you would use NTFS’s file security to permit direct file access only by system (or database) administrators. Second, you would need to write your database server application to take all the incoming data requests from various users and provide the additional level of security based on permissions that you have previously defined at the user or group levels. This server application, by the way, would itself be able to access the database file directly, because it would run using the Administrator (or other appropriate) access rights.
WARNING
When implementing security on any object that might be accessed from outside your application, always restrict any and all direct access (file, communications, and so on) to this object by also using Windows NT’s built-in security attributes, wherever applicable. Typically, this means setting Administrator-only access on all “outside” approaches to your object, then having your server application internally make further decisions about granting or denying access on a case-by-case basis.
As you may surmise, it is generally foolhardy to attempt to implement security from within your application when either the application or its data files will end up being stored on a FAT (or other non-NTFS) partition. You could get around this partially by using encryption on your data files, as discussed later in this chapter. However, even with encryption, there are likely to be security loopholes if users are able to directly access your application’s data in any way.