A Windows NT system object, in the context we are using in this chapter, does not mean a C++ object, an OLE object, or a COM object. Here, it refers to any “object” created and managed by one of the three main Windows NT subsystems: Kernel, User, and GDI.
Figure 20.1: Each user logged in to Windows NT is represented internally by an access token. Each system object (or user object) is identified by a security descriptor.
For various reasons, NT’s built-in security is only implemented on Kernel objects. Thus, you are not required (via the API) to worry about security when creating objects such as bitmaps, cursors, pens, brushes, icons, metafiles, or window handles. But you do need to provide at least a security descriptor parameter (or a NULL value) when creating or managing Kernel objects, such as files, folders, storage devices, pipes, mailslots, serial ports, registry keys, console devices, and printer queues.
In addition to system objects, there are also user- or application-defined objects. These are any objects that your application defines, creates, and recognizes. These types of objects can include anything from particular functionality in your application, to NT objects from the User and GDI subsystems (if you need to protect a bitmap, for instance), to subdivided areas of files. This category also encompasses anything else your application must interact with and control access to—a piece of data, a menu command, a particular view of a dataset, or whatever else you might come up with.
NOTE
Sometimes, a further distinction is made between Windows NT objects created by NT and NT objects created by end users, via their use of the system or various applications. This distinction becomes important in understanding the difference between SACLs and DACLs, as we’ll discuss later at the chapter.