| Previous | Table of Contents | Next |
SCO UNIXware is equipped with a more granular notion of capabilities than most UNIX variants. Specific privileges can be granted to users, such as the following:
Many other privileges, usually defined for management tasks, exist as well. The purpose of this feature is to provide more flexibility in delegating administrative tasks. Thus, a user can have increased privileges on a system for performing some administrative tasks without knowing the root user’s password. A little known feature of IBM’s AIX operating system is that it also contains a data structure supporting privileges, although the design was never implemented as fully as in SCO UNIXware. Products, such as those provided by Tivoli, discussed briefly at the end of this chapter, have been introduced to layer this feature on most versions of UNIX.
In Chapter 2, you saw how to control who can log in and begin interacting with the computer. Many processes already are running on the system before you even log in. These processes and applications, of course, have a security context. That is, they are tagged with UIDs and GIDs so that appropriate access limitations can be enforced. How does such a process get its security credentials or context?
Most operating systems have a common startup process. The details naturally vary across manufacturers, but the following high-level description should suffice. When the computer is turned on, the system’s hardware performs various power on self tests (POST). These checks look for memory, processor, and bus problems. Usually, a programmable ROM (PROM or EPROM) has been set to look into a special memory location called nonvolatile random access memory (NVRAM). The NVRAM contains various types of configuration information for the system, especially data on how to boot the operating system. The CPU loads this boot information that typically points to further boot instructions stored on disk in a special boot record. The boot record points to a minimal version of the operating system kernel that is then loaded into the CPU. This kernel then overlays itself with the full kernel found on the disk.
The kernel typically initializes a process from which all other processes are created. This init process starts with the root user ID. When other processes are started as children of this initial process, their security credentials will be the same unless the operating system is configured to run them with other privileges. For example, the mail daemon on most systems is usually run with a GID for the group mail. The default UNIX /etc/passwd file shown in the preceding chapter should give you an idea of the possible UIDs that background processes might be launched with when a UNIX system boots. There really isn’t any magic in how this works. The system is still using the basic notions of process inheritance or explicit system calls to establish the credentials of these special programs.
In NT every access control reference goes through a single reference monitor (except for applications that implement their own reference monitors). In the long run, this architectural model is better to use for security. The same architecture is found on mainframe computers and implemented by products such as RACF, ACF/2, and TOP SECRET. Even though the architecture is good, the implementation can still be flawed. NT has had its fair share of hack attacks.
Like UNIX, NT makes decisions based on subjects, objects, and access control lists. To begin with, the NT reference monitor must know the subject of the request in order to evaluate whether to permit the operation.
What you can do in NT is a combination of the rights you have and the access control rules defined for objects you want to manipulate. The NT operating system contains more than 27 specific rights. The rights you have are formed from the union of any rights assigned to you as an individual plus any rights defined for groups to which you belong. Example rights include the ability to log in to a system from the network, the ability to log in locally to a system, the ability to impersonate other users, the ability to back up files, and the ability to create new users. A particularly powerful right is the ability to act as part of the operating system. Naturally, you would not want everyone on your system to be able to have this right.
To simplify administration of the environment, default users and groups are enabled as part of the standard NT installation. These users and groups are assigned sets of rights to perform tasks on the system. For example, the default group Backup Operators have the ability to back up and restore files but not the right to add or change users. Like default settings for file and directory permissions, no proof that the default settings are secure exists. A weakness in NT, or in a privileged application running on NT, which can be used by a hacker to increase access rights, is a serious problem. The widely publicized GetAdmin hack is an example of how an arbitrary user is able to gain Administrator rights. In this hack, a normal user was able to write a global memory variable in the NT address space, which gave the user Administrator rights after the next login session.
In the preceding chapter, it was shown that the NT login process finishes by creating a desktop process for you and associating with it an access token. The access token contains your unique security identifier (SID), your primary group SID, and the SIDs for any other groups to which you belong. Access control rules in NT specify the subject using the SID of a user or the SID of a group. See Chapter 10, “Intrusion Detection For NT,” for a peek at the contents of an access token.
| Previous | Table of Contents | Next |