Bill and Lynne, the authors of 386BSD, can be contacted at lynne@bsdserver.ucsf.edu.
With the flood of PC-based systems running TCP/IP, the number of Internet hosts--now at 3.8 million--has increased dramatically, with a projected 100 million hosts by 1999. But as the now-infamous Morris worm demonstrated, connecting to the Net brings with it the problem of system security. Of course, there are facilities and packages such as Kerberos that can mitigate this risk, but they require overhead to implement and administer. Since most PC environments are managed by a single person (often the user), system management is often taken care of by someone who has neither the time nor expertise to properly implement and maintain security measures.
"Role-based security" is a mechanism orthogonal to the familiar authentication, encryption, and threat-detection mechanisms. It is a minimal mandatory access control (MAC) policy that restricts access with a low-level abstraction mechanism that is hard, if not impossible, to bypass, yet requires little knowledge or maintenance from the user. Role-based security derives its name from the concept of roles used to simplify the description of allowable access characteristics of a host's user. Coupled with the concept of access path, roles provide a degree of geographic classification (where the user is located) to determine a specific role. Consequently, roles determine the scope of access a user has to files and privileged operations.
It is always difficult to balance the need for a secure environment with convenience and accessibility. Typically, the routes to access are mediated by "locks" requiring a "combination" (password authentication) and file-access-mode discretionary access control (DAC). Account passwords provide a reasonable degree of security when machines are relatively isolated. With network access and some work, however, an intruder can either "pick" the combination of an account or intercept the use of the password as it transits the network. An intruder can also easily "case" large numbers of network host computers looking for vulnerabilities (stale/common passwords, alterable system control files, and so forth). In short, machines can be compromised even if the intruder has no idea where the machine resides or what it looks like.
Many existing facilities and packages have been enhanced to cope with this increased threat. Among the most basic packages are Kerberos and COPS, which plug holes by beefing up existing authentication mechanisms, while attempting to discover vulnerabilities before the "bad guy" does. Kerberos-extended network utilities (rlogin, ftp, and telnet) also encrypt communications to avoid passing information in clear text where it might be intercepted.
Unfortunately, these solutions require additional administrative overhead because they are yet another facility which must be maintained. Moreover, this overhead increases with the sophistication of the security mechanisms and the model of security that it attempts to reach. Failure to attend to the system-management details required to keep such systems current may compromise the integrity of the entire system, thereby defeating the purpose of these facilities in the first place.
Like network-gateway firewalls, role-based security is simple to employ yet hard to bypass. In effect, the firewall is integrated into the operating system, so that it surrounds files, sockets, and system facilities. Unlike a gateway firewall, it does not require administration and monitoring to review new access requirements and intrusion attempts. The role-based security model consists of:
In many secure systems, privileges are recorded as bits set in a "list of privileges" (a bit vector of all the privileges). Most privileges revolve around system-management functions such as manipulating or adding new devices; reformatting disks; changing the access, protection, or ownership of a file; and so forth. As a system is enhanced, more privileges are added. You may even create privileges merely due to the existence of other privileges as a way of enabling groups of them or offering special treatment. At some point, the management or control of these privileges becomes a formidable task in itself (386BSD has more than 50 distinct privileges).
Rather than affording such a fine-grain, difficult-to-manage concept, the list-of-privileges model can be replaced by a "role" model. A role is akin to an actor's assigned character. Unlike traditional UNIX systems (which have one ultimate privilege, called the "superuser" or "root account"), systems using role-based security identify the use of privileges inside the kernel on a case-by-case basis. The role concept is essential to compressing the complexities of the model of security, much as the description of a character at the beginning of a book provides an intrinsic understanding of that character over the course of the story.
Roles compress the notion of privilege. If new privileges or file-access rights are added to the system, they are added only to suit the needs of roles--the roles themselves generally do not change. This means that although security needs in the operating system become more elaborate, the model stays "simple" from the user's perspective.
Unlike the UNIX setuserid/setgroupid features that allow another group or user ID to be used as a proxy, roles are set once by the access path and never allowed to change--they are independent of these user/group ID concepts. Roles are then used by lower levels of the kernel to bound access.
A user accesses information or services from the computer via an "access path." This may be done through physical access to the computer console, an attached serial line, or network communications. Roles are defined by the access path to the computer; thus, the way in which the information is accessible may differ, depending on the information's destination. Since the mechanisms that determine path are extremely low level, the bad guy must find ways to "imitate" access, by either gaining or simulating physical access.
With a role-based model, the scope of access is limited without increasing system-management overhead--no user-account profile need be maintained. For example, to gain fundamental access to management functions (through which most computers are subverted), you must know not only the passwords but also the required setting. This geographic determination makes it far more difficult for an intruder, who must now attempt to subvert all of the mechanisms that determine knowledge of geographic location. Thus, access path qualifies a user to access restricted privileges and files in the same way that a password is used to authenticate a user.
Many attempts at improving operating-system security affect both the operating system and the host on which it is installed. As such, it may be almost impossible to remove the security mechanism because it is interwoven into the system. This makes such security mechanisms less desirable.
With a role-based model, a high degree of transparency is a requirement; otherwise it would be too troublesome for a user to consider employing it. The demand for transparency affects all areas of the role-based security design:
Another requirement for a secure system is that it provide a mechanism which can "guarantee" that certain sensitive files can be accessed only by certain characters playing these roles--even if a more trusted role is "tricked" by a lesser one. A MAC policy is thus used to maintain the integrity of the information by ensuring that any files that may contain elements of the information be kept at the same restricted access as that of the original file. Consequently, the system is mandatory in that the computer, not the user, maintains the restrictions in all cases so that a user who may not be aware of a program's scope of vulnerability does not inadvertently compromise the information.
With role-based security, files can be marked so that contents cannot be sent outside of a specified geographic zone (currently, host, local network, and external network). Once marked, even if a privileged account is compromised, the information of a file so marked cannot be obtained outside of its restricted zone. Files created by programs using such restricted files are de facto restricted as well, avoiding the accidental release of information outside of the zone. This effect is achieved without altering the user program environment or interfering with existing industry standards (such as POSIX). Thus, it can be added (or removed) from a system without affecting any existing programs other than the kernel.
MAC is complementary to discretionary access control (DAC), which in a UNIX system corresponds to the permission attributes of read/write/execute access methods across user, user group, or system. (Many UNIX systems extend this concept still further with the Multics-like concept of an Access Control List, or "acl," which allows access rights to be specified on a per-user basis--this mechanism also presents advantages and problems of an extreme sort.)
The virtue of MAC is that it is automatically managed--the user need not be aware of it. Many UNIX systems, in contrast, are compromised simply because the user does not manually set the access-permission bits properly so that other users cannot read or write a file. With MAC, the operating system automatically supplies the restriction.
By reducing management of restricted files to one simple operation that is further managed by the system automatically in a fail-safe way, the user obtains the benefits of a secure environment without having to intimately manage such details. Since the mechanism is implemented at the lowest levels of abstraction in the system, it is almost impossible to subvert directly.
In the 386BSD 1.0 implementation of role-based security, there are four roles. The primary role (purposely put into the background) controls the lion's share of administrative privileges. The secondary role has access to most of the privileged files, plus the ability to mark/unmark files as "privileged." The third role can obtain access and mark as privileged a much-lesser grade of files; it also has the ability to go between systems on the immediate LAN to which the computer is attached. The last role is the least trusted. Since the only thing we know for certain is that someone has come in from outside the LAN, we don't trust him/her with anything privileged. Thus, any attempts to invoke any substantive privilege or access to a privileged file will not be successful. What is common among all of these roles is that we identify them solely by the way in which they gain access to our system, each in varying degrees of trusted path, with the last being trusted the least.
With 386BSD role-based security, a user assigned either the second or third role can indicate a "sensitive" file by setting a mode on a directory in which that file lies. A sensitive file cannot be referenced outside of the scope of access allowed to those two roles. Thus, a file may not have its contents sent by any user across the network if it is marked in this manner. If the file is copied to another file or incorporated into a portion of another file, the new file by default will likewise be marked at the level of the most sensitive part incorporated into it.
With this implementation of network-level, role-based security, files can be restricted to remaining on the host computer (when information should be restricted to a user's own PC) or within the immediate local area network (when the LAN is considered to be adequately secure, yet the information should not be accessible or distributed outside of the LAN organization).
While role-based security can be extended into a more elaborate arrangement, its primary advantage is simplicity: It fits easily into any extant modern operating system, and it is easy to understand and administrate, yet hard to subvert because it remains so fundamental. This approach avoids the possibility that as the complexity increases, holes develop that may ultimately defeat the entire point. Simplicity helps you avoid this.
Another advantage of this simple arrangement is that, since you must be physically present to install an operating system anyway, it is possible to incorporate security at this point without requiring additional administrative hurdles to gain access to simple, straightforward procedures. Easing the decision-making burden for the user during installation in a "safe" way is critical, since it is at this time that a user will know the least about what items to secure. For example, a naive user wishing to prevent any possible disclosure of personal files need only mark the home directory of his account as being "not accessible" over a wide area network--the computer itself takes care of sensitive, system-related files automatically.
The greatest strength of this approach is also its greatest weakness--its inflexible binding of privilege and access rights with the path of access. This mechanism is so low level that it is nearly impossible to bypass, even when you want to read a privileged file via the network.
Likewise, remote system management is impeded. However, since a user/administrator generally does his own system administration on-site (there really are no good network-based system-management tools intended for a single user/administrator yet), this currently isn't a problem.
To remove the restrictions on a particular file, a utility is needed to allow a user with the appropriate role to remove restrictions. This utility, however, requires authorization directly from the console through a known secure path. If the authorization is not supplied, the restriction is not removed. For example, suppose the bad guy somehow got a user running with a privileged role to execute something useful for the bad guy--in this case, the console would unexpectedly request authorization. The attempt at subversion could be tracked down and the bad guy revealed, all without loss of integrity. (Note that this is the only "violation" of our mandatory access-control policy possible and it is again tightly controlled--it is a convenience for operation only.)
Role-based security, like other security mechanisms, is not foolproof. However, the roles provide the scope of access to privileges and restricted files and are governed solely by access path. Clearly, the easiest way to compromise the system is to gain access to a trusted path. Thus, role-based security is not intended to deal with "insider" related threats. The implicit assumption is that physical access to the machine itself is trusted, and access to the immediate LAN is trusted within limits.
For many people putting PCs on the Internet, security considerations often get lost in the difficulty of just installing the software, connecting to the network, and learning the ropes. Role-based security is not intended as a complete answer for all security needs--but it will give Morris wanna-bes a harder time and save you aggravation.
Copyright © 1995, Dr. Dobb's Journal