Access Control is at the heart of a trusted system. Access control allows the administrators to set up policies and accounts that will allow each user to have full access to the files and resources he or she needs, but not to other information and resources not immediately necessary to perform assigned tasks.
Under Trusted IRIX/CMW, There are two forms of Access Control, and these are called Discretionary Access Control and Mandatory Access Control. Mandatory Access Control is further divided into two interrelated subsystems, Mandatory Sensitivity and Mandatory Integrity.
Discretionary access control is the name of the standard UNIX system of access permissions that allow the user to control access to files, directories, and other system resources. The owner of any file or other system object can control access to that object, even by those with equal or dominating clearances, by setting the DAC permissions. Additionally, Access Control Lists (ACLs) can be used to provide a finer granularity of control than provided by the traditional permission bits.
The significant difference between MAC and DAC is that DAC allows untrusted users to control access to their own files and change that access at will. The only user who can override those access decisions is the Superuser (root). DAC fills an otherwise unmet need for system security at the personal level. Every file on the system is subject to both MAC and DAC. You must meet both MAC and DAC requirements to access a file.
Trusted IRIX/CMW divides permissions into three categories, and users into three relative groups. The three categories of permissions are read, write, and execute. They are denoted as “r” for read, “w” for write, and “x” for execute in long listings of files. To get a long listing, type
ls -l |
at your system prompt in any directory. The command shows you more information about the files in the directory than an ordinary listing. Along with the permission information, the ls -l command lists the owners of the files and the size of the files and the date they were last modified. Adding the -D command line option to ls displays the Access Control List for the file or directory as well.
Read permission allows you to look at the contents of a file. Write permission allows you to make changes to or remove a file. Execute permission allows you to run the file as a command from your shell prompt.
The three relative groups are the owner of the file, the owner's group, and every other user. If you get a long listing of a directory, you see that the permissions field looks like this: -rw-r--r-- Each character is separately significant in the permissions listing. Starting at the left, the first character is a dash. A dash in any place means that no permission is granted and the actions associated with that permission are denied. However, in the leftmost place, the contents of that space describes whether the file is a file, directory, or special device file. If there is a dash in that place, the file in question is an ordinary file. If it is a directory, a “d” appears in that space. If the file is a block special device file, a “b” appears in the space, and if the file is a character special device file, a “c” appears there. For more complete information, consult the ls(1) reference page or the /usr/include/sys/stat.h file.
Directories use the same permissions as files, but that their meanings are slightly different. For example, read permission on a directory means that you can use the ls command to look at the contents of that directory. Write permission allows you to add, change, or remove files in that directory. (However, even though you may have write permission in that directory, you must also have write permission on the individual files to change or remove them, unless you own the directory.) Finally, execute permission on a directory allows you to use the cd command to change directories into that directory.
The first series of three places in the permissions field describes the permissions for the owner of the file. Here is an example of a long listing for a file:
-rwx------+ 1 owner grp 6680 Apr 24 16:26 shell.script |
The file is not a directory, so the first space is blank. The characters rwx indicate that the owner of the file, owner, has read, write, and execute permission on this file. The second series of three spaces describes permissions for the owner's group. In this case, the group is grp. If permissions for this file were slightly different, like this:
-rwxr-x---+ 1 owner grp 6680 Apr 24 16:26 shell.script |
then any member of the group grp could read or execute the file, but he or she could not change it or remove it. All members of group grp can share a pool of files that are individually owned. Through careful use of group read and write permissions, you can create a set of source files that are owned by one person, but any group member can work on them.
The third series of spaces provides for all other users on the system and is called the public permissions.
The plus sign (+) at the end of the permission string indicates that an Access Control List is in effect for this file. Use the ls -D command to view the Access Control List for the file. Complete discussion of Access Control Lists is found in the section titled “Access Control Lists.”
On a large system with several groups, MAC labels do not provide the complete coverage desired. The individual groups can tailor their working set of files by using file permissions and Access Control Lists to share some files. A file that is set to be readable by any user on the system is called publicly readable. Remember that even if DAC makes a file publicly readable, a user must still have appropriate MAC clearance to see the file.
Here is a long listing of our sample Projects directory:
total 410 drw-------+ 1 owner grp 48879 Mar 29 18:10 critical -rw-r--r-- 1 owner grp 1063 Mar 29 18:10 meeting.notes -rw-rw-rw- 1 owner grp 2780 Mar 29 18:10 new.deal -rwxrwxrwx 1 owner grp 8169 Jun 7 13:41 new.items -rw-rw-rw- 1 owner grp 4989 Mar 29 18:10 outside.response -rw------- 1 owner grp 23885 Mar 29 18:10 project1 -rw-r----- 1 owner grp 3378 Jun 7 13:42 saved_mail -rw-r--r-- 1 owner grp 2570 Mar 29 18:10 schedules -rwxrwxr-x+ 1 owner grp 6680 Apr 24 16:26 shell.script |
The files have varying permissions. Some are read/write only for the owner, some can be read only by members of the owner's group, and some can be read, changed, or removed by anybody. The shell script can be executed publicly, subject to its ACL, and the critical directory is also subject to an ACL.
You change the permissions on a file by means of the chmod(1) command. You can use chmod only to change files that you own. Generally, you use this command to protect files you want to keep secret or private, to protect private directories, and to grant permissions to files that need to be used by others. The command to restrict access to a file or directory to yourself only is:
chmod 600 filename chmod 700 directoryname |
Other permissions may be added by using the chmod command with the letter associated with the permission. For example, the command to add general write permission to a file is:
chmod +w filename |
For more examples, see the chmod(1) reference page.
To set or change an Access Control List, use the chacl(1) command:
chacl acl_entry [, acl_entry ] ... |
For more information on chacl and the acl entry syntax, see the chacl(1) reference page and the section of this chapter titled “Text Form Representation of ACLs.”
You can decide what default permissions your files will have by means of the umask command. You place this command in your .cshrc, .profile, or .login file. The umask(1) reference page is also available for more information. By changing the setting of your umask, you can alter the default permissions on your files and directories to any available DAC permission.
A drawback to the umask command is that it makes every file you create receive the same permissions. For most purposes, you want the files you create to be accessible by the members of your group. For example, if an individual is suddenly called away and another person must take over that person's portion of a project, the source files must be accessible by the new user. However, the personal files you keep in your home directory sometimes need to be private, and if you set your umask to allow group read and write privileges, any member of the group can access your personal files. But mechanisms are available to prevent this access. For example, you can create a directory of private files and alter the permissions on that directory with the chmod command to restrict all but your own access. Then it would not matter that the files were readable, because no other user would be allowed into the directory.
You can also use the find command to change all the files in your home directory to your chosen permission automatically at your convenience. You can set up your account so that this action happens every time you log out.
The umask command is an important part of DAC. It allows us to maintain security and still allow convenient access to your files. To set your account up to allow group read and write privileges and no other privileges, place this line in your .cshrc or .profile file:
umask 007 |
This will make every file you create have the following permissions:
-rw-rw---- |
With your umask set to 007, directories that you create have the following permissions:
drwxrwx--- |
In plainer terms, you will have full use of the file or directory, and your group will have full use. No other user, except the Superuser (root), will have access to your files.
Access Control Lists (ACLs) are a part of the Discretionary Access Control Features of your Trusted IRIX/CMW system. An ACL works in the same way as standard file permissions, but it allows you to get a finer level of control over who may access the file or directory than standard permissions allow. ACLs allow you to specify file permissions on a user by user basis.
Every system file or directory has an Access Control List that governs its discretionary access. This ACL is referred to as the access ACL for the file or directory. In addition, a directory may have an associated ACL that governs the initial access for files and subirectories created within that directory. This ACL is referred to as a default ACL. A user who wishes to gain access to the files in a directory must be on both ACLs and must be allowed by MAC and Trusted IRIX standard file permissions to successfully gain access. If you have not created an access ACL for a file, the default ACL serves both ACL functions. Note that the ACL on a file or directory also acts as an upper limit to the file permissions that can be set automatically with umask.
Hereafter in this section, directories are treated as files, and where the term file is used, consider it to also apply to directories.
An ACL is stored in the same way that standard file permissions are stored; as an attribute of the file or directory. To view the ACL of a file, use the -D option to ls(1) as shown here:
ls -D /usr/people/ernie/testfile |
This produces output similar to this:
testfile [user::rwx ,user:332:r-- ,user:ernie:rw-]
The above example shows full permissions for the owner with the first entry on the line, sets read permission for user ID 332 with the second entry, and sets read/write permission for the user account ernie. The format of an ACL entry is discussed in the section titled “Text Form Representation of ACLs.”
To set or change an ACL, use the chacl(1) command:
chacl acl_entry[,acl_entry]... |
An ACL consists of a set of ACL entries. An ACL entry specifies the access permissions on the associated file for an individual user or a group of users. The order of internal storage of entries within an ACL does not affect the order of evaluation. In order to read an ACL from an object, a process must have read access to the file. In order to create or change an ACL , the process must own the file.
To set a default ACL for the current directory and all its files and subdirectories, use the command:
chacl -d acl_entry[,acl_entry]... |
For information on the format of an ACL entry, see the section titled “Text Form Representation of ACLs.”
This section defines the long and short text forms of ACLs. The long text form is defined first in order to give a complete specification with no exceptions. The short text form is defined afterwards because it is specified relative to the long text form.
The long text form is used for either input or output of ACLs and is defined as follows:
acl_entry[,acl_entry ]... |
Though it is acceptable to place more than one entry on a physical line in a file, placing only one entry per line improves readability.
Each entry contains one ACL statement with three required colon-separated fields and an optional comment:
entry tag type:entry qualifier:discretionary access permissions # comment |
Comments may be included with any entry. If a comment starts at the beginning of a line, then the entire line is interpreted as a comment. The first field must always contain the ACL entry tag type.
One of the following ACL entry tag type keywords must appear in the first field:
| user | A user ACL entry specifies the access granted to either the file owner or to a specified user account. | |
| group | A group ACL entry specifies the access granted to either the file owning user group or to a specified user group. | |
| other | An other ACL entry specifies the access granted to any process that does not match any user, group, or implementation-defined ACL entries. | |
| mask | A mask ACL entry specifies the maximum access which can be granted by any ACL entry except the user entry for the file owner and the other entry. |
The second field contains the ACL entry qualifier (referred to in the remainder of this section as simply qualifier).
The following qualifiers are defined by default:
| uid | This qualifier specifies a user account name or a user ID number. | |
| gid | This qualifier specifies a user group name or a group ID number. | |
| empty | This qualifier specifies that no uid or gid information is to be applied to the ACL entry. The entry applies to the file owner only. An empty qualifier is represented by an empty string or by white space. |
The third field contains the discretionary access permissions that are to apply to the user or group specified in the first field. The following symbolic discretionary access permissions are recognized in ACLs:
Read access
Write access
Execute/search access
No access
The discretionary access permissions field must contain exactly one each of the following characters in the following order:
r
w
x
Any or all of these may be replaced by the no access character (a dash):
-
A user entry with an empty qualifier specifies the access granted to the file owner. A user entry with a uid qualifier specifies the access permissions granted to the user name matching the uid value. If the uid value does not match a user name, then the ACL entry specifies the access permissions granted to the user ID matching the uid value.
A group entry with an empty qualifier specifies the access granted to the default user group of the file owner. A group entry with a gid qualifier specifies the access permissions granted to the group name matching the gid value. If the gid value does not match a group name, then the ACL entry specifies the access permissions granted to the group ID matching the gid value. The mask and other entries contain an empty qualifier. A hashmark (#) starts a comment on an ACL entry. A comment may start at the beginning of a line, or after the required fields and after any custom-defined, colon-separated fields. The end of the line denotes the end of the comment.
If an ACL entry contains permissions that are not also contained in the mask entry, then the output text form for that entry must be displayed as described above followed by a hashmark (#), the string "effective: ", and the effective file access permissions for that ACL entry.
White space is permitted (but not required) in the entries as follows:
at the start of the line
immediately before and after a colon (:) separator
immediately before the first hashmark (#) comment character
at any point after the first hashmark (#) comment character.
Comments have no effect on the discretionary access check of the object with which they are associated.
Here is an example of a correct long text form ACL for a file:
user::rwx,user:332:r--,user:ernie:rw- |
The above example sets full permissions for the owner with the first entry on the line, sets read permission for user ID 332 with the second entry, and sets read/write permission for the user account ernie.
Here are some examples with comments:
group:10:rw- # User Group 10 has read/write access other::--- # No one else has any permission mask::rw- # The maximum permission except for the owner is read/write |
The short text form is used only for input of ACLs and is defined as follows:
acl_entry[,acl_entry ]... |
Though it is acceptable to place more than one entry on a physical line in a file, placing only one entry per line improves readability.
Each line contains one ACL entry, as defined in “Long Text Form for ACLs” with two exceptions. The ACL entry tag type keyword must appear in the first field in either its full unabbreviated form or its single letter abbreviated form.
The abbreviation for user is u, the abbreviation for group is g.The abbreviation for other is o, and the abbreviation for mask is m.
There are no exceptions for the second field in the short text form for ACLs. The discretionary access permissions must appear in the third field in either absolute symbolic form or relative symbolic form.
The relative symbolic form must be preceded by a plus sign (+) to indicate additional access or a caret (^) to indicate that access is to be removed. The relative symbolic string must be at least one character.
The symbolic string contains at most one each of the following characters in any order:
r
w
x
For example, the short form should look very similar to the following:
u: :rwx # The file owner has complete access u:332:+r # User Acct 332 has read access only g:10:rw- # User Group 10 has read/write access u:653:^w # User Acct 653 (who is in group 10) has read access only o::--- # No one else has any permission m::rw- # The maximum permission except for the owner is read/write |
Capabilities are another form of Discretionary Access Control. A file or directory may have a capability requirement associated with it, and only those users specified as having the particular capability will be allowed to access the file or directory.
The fundamental purpose of capabilities is to allow users to perform system administration from standard user login accounts without requiring the use of Super-User or other sorts of privileged accounts. Your Site Security Officer will let you know if you are expected to use capabilities or if you are to perform a role in system maintenance.
A capability may be granted to any user account, and a corresponding capability requirement attached to only those system files that the owner of the account has a legitimate need to access. This follows the trusted systems principle of least privilege – using the lowest possible promotion of privileges necessary to get the job done.
The file /etc/capability is the database of capabilities for user accounts. Here is a sample /etc/capability file:
root:all+eip:all+eip sysadm:all=:all= auditor:CAP_AUDIT_WRITE,CAP_AUDIT_CONTROL,CAP_KILL+eip dbadmin:all=:all= ernie:all=:CAP_FOWNER,CAP_SETFCAP+eip casey:all=:all+eip |
The capabilities listed in the /etc/capability file apply by default to all processes invoked by that user.
All system objects (files, directories, executables) may have capability requirements attached to them. These capability requirements work in concert with Mandatory Access Control, file permissions, and ACLs to determine who may have access to the object. A user must pass all requirements to be able to access a file or directory – having a capability does not bypass any other requirements.
File or directory capabilities are set with the chcap(1) command. The syntax is as follows:
chcap CAP, CAP, CAP |
For example, to set capabilities to match those associated with the auditor account above, use the command:
chcap CAP_AUDIT_WRITE,CAP_AUDIT_CONTROL,CAP_KILL+eip |
To list the capability requirements of a file or directory, use the command:
ls -P
The -P flag stands for "Privilege." Note that you must have the appropriate capabilities to read the file in order to read the capabilities of the file.
One of the new features in Trusted IRIX/CMW and in B-level trusted systems that is not available in standard IRIX is Mandatory Access Control. Mandatory Access Control is essentially different from Discretionary Access Control in that the restrictions placed on file and resource access are not up to the discretion of the individual user, but are mandatory for all users. The system enforces Mandatory Access Control through the security labels of all files, programs, resources, and processes (including user processes) on the system. The concept of label domination and equivalence is used to make Mandatory Access Control decisions. After the sections describing the subdivisions of Mandatory Access Control, there is a section describing the rules of label domination and equivalence.
As mentioned above, Mandatory Access Control is divided into two parts, Mandatory Sensitivity and Mandatory Integrity. These two concepts work in concert to provide a trusted environment for the users.
Mandatory Sensitivity is a mechanism for implementing strict controls on access to data. A privileged user can never give information protected by Mandatory Sensitivity to someone who is not allowed to see it. Under DAC, a user can change a file's permissions so that any user can read, write, or execute the file. This system provides a good level of security in an open system but does not provide the level of security needed by Trusted IRIX/CMW. MSEN works in addition to DAC to provide an extra level of security.
MSEN defines two different kinds of permissions. One kind is for the user and the user's login shell process; the other is for system objects, such as files. The first kind of permission, for users and processes, is called a clearance. A clearance permits a user or the user's process to use system objects with corresponding classifications.All of the processes that run on behalf of a user must be within the user's clearance.
Each clearance for a user and the processes associated with that user contains a level of clearance, such as confidential or proprietary. Each user's clearance can also be valid in a number of categories. These categories are used to divide files and information logically by relationship. For example, all development files could be in the category ENGR and all personnel files could be in the category HR. A user with clearance in the ENGR category would not necessarily have clearance in the HR category, even if the two categories are currently running at the same classification. The number and names of your clearances and categories are configurable at any time.
The combination of clearance and categories forms the MSEN label of a user or a user's process, while the combination of classification and category forms the MSEN label of an object.
An object (a file or system resource) is classified at a level of protection based on the judgment of some person. It is also defined to be in some number of categories. For example, employee salary records could be classified as top secret and in the categories HR, management, and finance. Thus, a user who is cleared for top secret data in the categories of HR, management, and finance could view the data, but a user cleared only to the level of secret could not. A user cleared to top secret in another category, such as ENGR, also could not view the information. To view information that has categories, you must also be cleared for the same or a strict superset of categories. For example a user cleared to top secret in only one category in our example, say finance, could not view the employee salary information.
For a person to access a secret file about employee records, the user must be cleared for both that level of secrecy and the category of information. Users cleared to levels higher than the level of a given file can also view the file. For example, a user cleared for top secret information can read a secret file, provided that the user is cleared in the proper category.
The Mandatory Integrity (MINT) system protects important users from files of questionable integrity. Until a program has been certified to be free of security risks, important users should not be allowed to execute it. Mandatory integrity enforces this restriction.
The MINT mechanism allows read and execute access only to those processes whose integrity labels are dominated by the object (meaning that the file or program has equal or greater integrity than the user process). Additionally, a process may only write to an object with the same integrity. This is to avoid reducing the integrity of a file by a user with lower integrity.
Mandatory Integrity is similar to MSEN in design and implementation, but addresses different issues and threats. While MSEN prevents a user from accessing information that is too sensitive or secret for the user's clearance, MINT prevents a user from accessing information or programs that are of unknown or lower quality or security. For example, a user running at the highest possible clearance who has access to the most secret and important system resources should not be allowed to run every program found on the system. Such a user should be permitted to execute only programs of known good integrity. This step further prevents Trojan Horse attacks on the system.
Consider the following scenario. A malicious intruder gains access to the system but only at the lowest level. This person creates a program to remove or publish certain system files and leaves the program in a public directory, calling it run.me. If a high-clearance user finds the file and executes it, serious damage could result. The solution is for the system to attach an integrity label to each file, indicating the known security of the file. A file created by a low-clearance user, such as our intruder, would automatically get a low-integrity label from the system. Any user with higher clearance would not see the low-integrity file when listing the directory contents, and any attempt to run the program would be denied access. Then, the Auditor would be notified of the denied access through the System Audit Trail, and the program could be safely removed.
Remember that a user's integrity requirement does not prohibit accessing files of greater integrity, only those of lower integrity.
MINT divides the objects of the system into divisions and assigns each file and resource a grade. MINT divisions need not be related to the categories used by MSEN on your system. For example, MINT divisions could be programming tools, general utilities, and administrative utilities. Thus, a user who has a MSEN clearance for ENGR might have a MINT requirement in programming tools, and in general utilities, but not in administrative utilities.
The concept of label domination and equivalence is central to MAC. If a user's label clearance is higher than an file's label classification and the integrity grade on the label of the file is good enough for the user's label, the user's label is said to dominate the file's label. If the clearance and classification on both labels are equal, the labels are said to be equal. A user's label must be at least equal to or must dominate an object's label in order to access the object.
When you add categories to MAC, you change the order of dominance on your system.In order to dominate, a user's label must have the same or higher sensitivity and a set of approved categories that are the same as or a superset of the categories of the file's label, and the integrity requirement for the user must be met by the file. Also, the integrity divisions of the user must be the same or a superset of the integrity divisions of the file.
Table 3-1 lists possible label relationships using the default labels supplied with your system. In the table, the levels of sensitivity are unclassified, proprietary, and company sensitive. The categories are green, gray, and gold. The integrity grades are good, choice, and prime. The integrity divisions are cake, cookie, and cracker. The labels are written in the form of sensitivity level-categories, integrity grade-divisions.
Table 3-1. Sample Label Relationships
Subject Label | Object Label | Dominates? | Explanation |
|---|---|---|---|
proprietary, good | unclassified, prime | Yes | Clearance dominated; integrity dominated |
proprietary, prime | unclassified, good | No | Integrity of the file not good enough |
proprietary-green, good | unclassified-green, good | Yes | Clearance dominates; categories equal; integrity equal |
proprietary-green, | proprietary-green, | Yes | Clearances identical |
proprietary-green, | company sensitive-green, prime | No | Object classification higher than user clearance |
proprietary-green, prime | proprietary-green/ gray, prime-cake/ cookie | No | Categories not equal or dominated |
proprietary-green/ gray, prime-cake/cookie | proprietary-green/ gray, prime-cake/ cookie | Yes | Categories equal; integrity equal |
proprietary-green/ gray/gold, choice | proprietary-green/ gray, prime | Yes | Categories dominated; integrity dominated |
Wildcard labels are special labels for system objects that are always equal to the label of any user process or other system subject that attempts access. For example, many system networking services are implemented through wildcard labels, so that all users can access the service. For example, the /dev/null device has a wildcard label.
While using Trusted IRIX/CMW, you will need to change your security label from time to time (if you are cleared for more than one label). You will also need to change the security label of a file from time to time, and you will frequently need to check the label of a file or resource. There is a group of commands that allow you to perform these activities easily.
Sometimes you will find it necessary to run a program or other process at a label different from your current login label. For example, the process may require a lower integrity requirement or a higher clearance. The newlabel(1) command allows you to run a process at a different label.
To prevent inappropriate transfers or disclosures of information, all open file descriptors associated with your login shell process are closed before the new process is invoked. This assures that information at a higher classification will not be used as any input to the new process, which may be running at a lower clearance. The default new process is your default command shell, as specified in your environment.
Remember that you can execute newlabel only with a specified clearance up to the maximum allowed for your login account. For complete information about newlabel, consult the newlabel(1) reference page.
To execute this command, type:
newlabel label command |
where label is the new security label you want and command is the command to be run at the new label. Assuming the label you have chosen is within your label range, the label is changed immediately for the duration of the command. Remember that only root (the Superuser) can use newlabel to run a shell.
You are allowed to change the label of any file or program you own, so long as you only upgrade the sensitivity label of the file or downgrade the integrity label. That is, the new label cannot be less sensitive or of higher integrity than the old label. What Trusted IRIX/CMW does when you change the label is to make a copy of the file at the new label, thus allowing the Site Security Officer to undo your change, if necessary. When you make the change, the new label of the file must be equal to the current label of the user attempting the change. Use the chlabel(1) command like this:
chlabel label filename |
Where filename is the name of the file to be changed and label is the new label for the file. The chlabel(1) command will only allow you to change the label to a label within your clearance range. Remember that the label of the directory that contains the file will not be changed, making future deletion or modification of the file impossible without administrator intervention. It is generally better to upgrade whole directories than individual files.
The -M flag to the ls(1) command displays the security labels for all files and subdirectories in the directory being listed. Note however, that only those files with labels dominated by your current label will appear in any directory listing, with or without the -M flag. If you ever find yourself in a situation where a file seems to have “disappeared”, check your label and make certain that the label of the file in question is dominated by your label.
Directories are subject to MAC just as any text file or other resource. Most directories have labels that are identical to any file label. The exceptions are called Multilevel Directories (which are sometimes called moldy directories or mld).
An mld places the files from each label into multiple hidden subdirectories. Thus, user A at label Q will get a different listing of the contents of the mld from user B at label X. However, neither process will see the subdirectory structure. Each process sees only those files in the mld that have the same label as the process.
The hidden subdirectories in an mld are visible to a user process which has a moldy label. A user may spawn a process with a moldy label using the -m option of the newlabel(1) command.