|
|
Discretionary Access Control (DAC) on a file defines the permissible access to it by its owner, the owner's group, and all others. It is discretionary because the protection on this data object is set at the discretion of the owner of the object. When the Enhanced Security Utilities are installed, DAC also includes Access Control Lists (ACLs).
Before discussing how Discretionary Access Control (DAC) provides a fine granularity of file protection, a review of the limitations and pitfalls of discretionary protection is in order.
First, the discretion to change permissions on data resides with the owner. If ownership of a piece of data is obtained by a malicious or incompetent user, nothing can prevent that user from destroying all discretionary protections.
Second, discretionary access controls cannot be used to prevent sensitive software or users from reading bad data, because the owner of a file can always make its data readable by the world, and the world includes sensitive people.
Finally, discretionary access is based on effective user and group identity. Effective identities change whenever a set-id-on-exec command runs, and they remain changed until the command sets them back to the real identities or exits.
Thus, sensitive discretionary access (and ownership) can be passed from a trusted command to an untrusted one by accident, exposing the system to attack.
SCO OpenServer protects sensitive data files by setting the ownership of all such files to root and supplying setuid-on-exec commands to give users controlled access to these files. This method provides protection because it makes protected files accessible only to the most restricted user.
This protection is adequate for most systems, but it is inadequate for protecting sensitive information on secure systems, because in practice, this has led to a proliferation of setuid-on-exec to root commands, some of which might be less careful than they should about propagating the root user identity to other commands. As a result, not only did the file protection begin to fail, but what had been the most restricted user identity suddenly became much easier to obtain.
The next attempt was to set up ``ghost'' user identities other than root to own sensitive files. Ghost user identities are user ID's in the system that are inaccessible as a valid user account (i.e. no one can login with this ID. Programmers using this technique managed to protect root somewhat better, but still left open the risk of Trojan Horse attacks on the files they were trying to protect. Finally, it became clear that giving away ownership to files made attacks too easy. Giving away group access was preferable. True, it was still possible to gain unauthorized access through imperfect system commands, but at least that access was limited to reading and writing.
The currently recommended DAC isolation method calls for the existence of a ``ghost'' owner: sys. This owner has a locked password entry, to make logging in as that user impossible. In addition, no commands can set their user identity to sys upon execution. This makes it impossible for a non-privileged process to obtain this user identity. Groups are defined to provide protection isolated according to the kinds of commands and users needing access to protected files. Administrators are assigned multiple group lists that allow direct access to protected files while normal users may gain access only through set-gid commands. All files protected by this mechanism are owned by sys and have the appropriate system group identity.