Access Control Lists

Access to objects or resources on a system are regulated by access control lists (ACL). At an abstract level, each object in the system is associated with an ACL. The ACL contains zero or more access control entries (ACE). An ACE contains enough information for the reference monitor to be able to decide whether the access request is permitted. Because an access request at least consists of the subject identifier and the access mode, the ACE contains this information at a minimum. For example, if a user with a UID of 7 wants to have write access to an object, the ACE conceptually contains at least the values {7, write}.

Although architectures vary, a generally accepted security principle is that the ACL should be stored with the object. That is, wherever the object is stored on the system, the ACL for that object also should be stored. Not all security models adhere to this idea. For example, DCE stores all ACLs in an ACL database. When an object, such as a software service, receives a reference request from an object, the object receiving the request performs a lookup in the database to evaluate the request. One reason this approach was adopted for DCE was to provide a general purpose access control framework for software servers. Object replicas could be located in multiple locations for redundancy and high availability, and all copies of the object could use the same single storage location for performing access control lookups. If you think this looks very much like a design tradeoff, with advantages and disadvantages for both approaches for ACL storage, you’re starting to understand the complexities of security models.

Who Are You?

An access control decision must be based on knowing the subject of the request. How does the system know “who” you really are? Unfortunately, the answer is complex, and because it is, systems get hacked. If a security model implementation could perfectly control access to resources, it would not be subject to attacks. You already know this type of control is impossible because of design flaws, programming errors, or administrative errors. Two of the most common ways to break a system are to change who the system thinks you are or to increase the privileges you have on the system. These themes will recur throughout the chapter as you explore access control in UNIX and NT.

Access Control in UNIX

In the UNIX operating system, access control can take many forms. Files and directories have permission bits that control how users and groups are allowed to access them. The subjects are the UIDs and GIDs that represent the users and groups, and the objects are the files or directories. UNIX also supports a number of IPC types including message queues, semaphores, and shared memory segments. Like the previous chapter, the scope of access control is considered here only in the context of a local computer without network connections. In the next chapter when you explore network security, both I&A and access control topics will be revisited to broaden their meaning to include network concepts. For the moment knowing “who” the system thinks you are, how you want to access a resource, and what access modes are supported by that object are the important items regulating access control.

Who Are You in the UNIX Environment?

In the preceding chapter, a simplified view of UNIX credentials was presented. You were told that the credentials consisted of a UID and one or more GIDs. In fact, several IDs are associated with a UNIX process, such as your login shell. These values include the effective user ID (EUID), the real user ID (RUID), the effective group ID (EGID), the real group ID (RGID), and secondary group IDs. In UNIX when your account is created, you are assigned to a primary group and one or more secondary groups. Your primary group value is copied into the RGID and EGID credentials fields when your login shell is started, and a separate field in the credentials data structure is set to contain the list of secondary, or supplementary, GIDs. Similarly, the RUID and EUID are initialized to the UID assigned to you when your account is created.

The RUID and RGID represent who you really are because these values are set by login and normally never change. The EUID, EGID, and supplementary GIDs are the values checked when you try to read a file or access another resource. These values primarily represent the subject of the request. In some cases, a programmer may want to check an access request for a resource using the RUID and RGID instead. The access() function is provided in UNIX for this explicit request. Generally, the EUID, EGID, and supplementary GIDs are automatically examined when access to a resource is needed.

On some versions of UNIX, two additional IDs are provided. The saved set-user-ID (SSUID) and saved set-group-ID (SSGID) are stored copies of the EUID and EGID, respectively. These values can be used to reset the UIDs and GIDs when the credentials for a process are changed during execution. More will be said about these fields later.

Finally, when you log in, an audit ID (AUID) is attached to your shell as well. In almost all cases, the AUID is equivalent to the UID reserved for you in /etc/passwd. When system auditing is turned on, your AUID becomes the prefix for every audit record logged for actions you perform. Auditing is discussed further in Chapter 8, “UNIX System Level IDSs.” With few exceptions, the AUID is really who you are on the system. During a normal interactive session with the computer, your EUID and EGID might change; your RUID and RGID are less likely to change but still might. Your AUID never changes unless a kernel service is explicitly requested to do so. Rarely does this occur, and when it does, an audit record is logged to show that the change occurred.