Your Trusted IRIX/CMW operating system comes with a small set of predefined labels. Do not delete these labels for any reason, since all but one of them are administrative. The defined labels are shown in Table 5-2:

Additionally, various default MSEN levels and MINT grades are defined in the /etc/mac_label directory. You may use these hierarchical components and the default categories and divisions to make more labels or you can define your own.

Equal (or wildcard) labels are a special type of label reserved for use by the system and by the Site Security Officer. An equal label is sometimes referred to as a wildcard label, since it always compares as equal in any label comparison. For example, a user running at userlow perceives the equal label as also being at userlow, while a user running at userhigh perceives that label as userhigh.

The administrative labels are dblow and dbadmin. These labels are not considered directly comparable with ordinary user labels. They are arbitrary definitions of the lowest and highest possible sensitivities on the system. These labels are generally reserved for system objects and administrative accounts. dblow files are considered to be part of the TCB, and they are of low sensitivity and the highest integrity. Thus, they are dominated by all labels and accessible to all users. For example, the /bin/cat program is available to all labels. dbadmin files are of the highest integrity and also of the highest sensitivity found on the system. These files contain data that must not be divulged or compromised. For example, the /etc/shadow file, which contains each user's encrypted password, is not available for general perusal.

No user should be able to log in at either of these labels, although exceptions are made for user accounts belonging to System Administrators.

Ordinary user labels (also called TCSEC label types) are those that the user sees in day-to-day work. Trusted IRIX/CMW is shipped with only one user-level label configured, userlow. As your user label library grows, remember to keep the hierarchy of labels clear and easy to understand.

User labels can be compared only with other user labels and equal labels. User labels always dominate dblow, and no user label can dominate dbadmin.

Batch processing jobs (such as those submitted through at(1), batch(1), and cron(1)) may be submitted at any label for which the user is cleared, and they are run with that label. Entries in crontab(4) files are also allowed at any label for which the user is cleared, with a separate file being maintained at each label requested.

It is possible to hold a multilevel label. You can give the:

newlabel -m 

command to change your current label to multilevel. The advantage to multilevel labels is that directories can also be made multilevel. A multilevel directory (or, sometimes, moldy directory or mld) places files of different labels into multiple hidden subdirectories. Each subdirectory bears the label of the files in that subdirectory. Thus, process A with label userhigh sees a different listing of the contents of the mld from process B with label userlow. However, neither process sees the subdirectory structure. Each process sees only files with the same label as the process in the mld. Once your label is multilevel, you can see the multilevel directory structure, but the rules of dominance are still in effect. You cannot see the contents of a subdirectory whose label you do not dominate, though you can see that the subdirectory exists. To create a multilevel directory, use the mkdir(1) command and then use the chlabel command with the -m flag and the name of the directory; the directory becomes multilevel.

Three types of mld labels are available to the root account: msenmldhigh, mld, and msenmldlow. msenmldhigh is a multilevel msenhigh clearance to give MSEN (though not necessarily MINT) dominance over all files on the system. mld labels at other MSEN levels are subject to the rules of dominance. msenmldlow is a multilevel dblow label for working with the TCB. You can log in with a multilevel label of one of these types, or you can log in at msenhigh/mintequal, dblow, or any label and use newlabel -m to make your label multilevel.

Frequently, you will find it necessary to check the label of a file or directory, or perhaps the labels of all the files in a moldy directory. For this purpose, Trusted IRIX/CMW supports the -M flag to ls(1). The ls -M command lists files according to the usual behavior of ls, except that the human readable names of the labels attached to the files or directories are displayed as well.

The id(1M) command displays the calling process ID number and name. It also displays the group ID and name. If the real and effective IDs do not match, both are printed. When invoked with the -M option, id reports the MAC label at which the invoking process is running.

attrinit -script=/etc/irixmac 

You can change the label of an object with the chlabel(1) command. Be aware that you must have access to the object before giving the command. You cannot use chlabel(1) to change the label of an inaccessible object. The new label cannot be less sensitive or of higher integrity than the old label. Additionally, the current label of the object must be equal to that of the process attempting the change. The -m flag to chlabel changes the label of a directory to multilevel.

The Site Security Officer may set a file or directory to any label. It is required that you have root privilege and to be logged in at an equal integrity to the object and either at the same sensitivity or system-high. If a user accidentally changes the label on a file and can no longer access the file, the Site Security Officer must downgrade the file for the user. The SSO is also the only user who may set an equal label. For complete information about the chlabel command, consult the chlabel(1) reference page.

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. The processes you may run include opening a new shell window.

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.

You may also use the su command with the -M option to execute a command at a higher label, provided you are cleared for that label, or have the password of an account that is cleared for that label. See the su(1M) reference page for complete information.

From time to time, it may become necessary to create new label names on your system, to adapt to changing usage and new projects. You also must create your starting set of labels when you install your system. A number of files define the sensitivity clearances and categories and the integrity grades and divisions. These files contain a “starter set” of predefined labels and label components for you to use. As you add your own labels to these files, remember that in no instance should you delete any of the distributed label components. Trusted IRIX/CMW depends on many of these defined labels and components. Also, remember as you edit these files that everything you put in them is case-sensitive. That is to say, the system differentiates between uppercase and lowercase letters in the names of the items. Also, each new label name must be unique. For example, you cannot use the name “good” for both a sensitivity level and an integrity grade. To add new label names, perform the following steps:

The following table is a short summary of the files in the /etc/mac_label directory:

Never delete a label name once it has been used on your system. Change all files that have the label to another label and remove the label from the ranges of all your users. Then, comment out the entry in the /etc/label/labelnames file by placing a crosshatch (#) at the beginning of the definition line. In this way, no one can use the label, just as if it had been removed, but a record remains that the label existed. This is necessary to prevent accidental reuse of the label for another purpose. If the name of a sensitivity level, category, integrity grade, or division is reused, a declassification of information could result. For example, if a sensitive file is left unchanged after a label is removed, and the label name is reused, that sensitive file is available to users not cleared for the information.

Trusted IRIX/CMW divides permissions into three categories, and users into three relationships. The three relationships are the owner of the file, the owner's user group, and every other user. If you get a long listing of a directory, you see that the permissions field for each file in the directory looks something like this:

 -rwxrwxrwx 

Note that the line of permissions has the string rwx repeated three times. The first instance of rwx applies to the file owner, then next instance applies to the group members, and the third applies to all other users on the system. The example above shows full permissions. A more restricted permission set might look like this:

-rw-r--r--

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. 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.

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.

Each character is separately significant in the permissions listing. Starting at the left, the first character is a dash. A dash in any other position 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 or a directory. If it is a directory, a “d” appears in that space. Other characters in this place indicate that the file is a pipe, a block or character special device file, or other type of file. See the ls(1) reference page.

-rwx------ 1 owner grp 6680 Apr 24 16:26 shell.script 

-rwxr-x--- 1 owner grp 6680 Apr 24 16:26 shell.script 

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 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 

chmod 600 filename 
chmod 700 dirname 

chmod +w filename 

chmod 700 budget personal letters 
chmod 600 budget/* personal/* letters/* 

umask 006 

-rw-rw----

drwxrwx---

The long text form is used for either input or output of ACLs and is set up 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:

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:

The third field contains the discretionary access permissions that are to apply to the user or group specified in the first field. The discretionary access permissions field must contain exactly one each of the following characters in the following order:

Any or all of these may be replaced by the no-access 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 umask and other entries contain an empty qualifier. A crosshatch (#) 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 umask entry, then the output text form for that entry must be displayed as described above followed by a crosshatch (#), 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:

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 by the chacl(1) command for input of ACLs, and is set up 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 command line contains one ACL entry, as defined in “Setting Permissions With umask” with the exception that 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:

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

You can use the output from the ls -D command as the input to chacl. This is convenient for situations where you wish to duplicate a complex custom ACL onto a new file in a directory that does not use the complex ACL as the default.

Consider this example. The command:

ls -dD testdir 

Produces the following output:

testdir [u::rwx,g::r-x,o::--x/u::rwx,g::r-x,o::---]

If you create a new directory (it doesn't matter where) with the command:

mkdir newdir 

And then use the following command to edit and copy the ACL (give this command all on one line):

chacl -b `ls -dD testdir | cut -d"[" -f2 |  cut -d"/" -f1``ls -dD testdir | cut -d"[" -f2 |  cut -d"/" -f2 | cut -d"]" -f1`newdir 

The ACL from testdir will be replicated in newdir. Note that the cut(1) command is used within the above command line. For complete information on the correct use of cut in any command line, see the cut(1) reference page.

After giving the above command, an ACL listing of newdir shows that the ACL from testdir has been duplicated:

ls -dD newdir 
newdir [u::rwx,g::r-x,o::--x/u::rwx,g::r-x,o::---] 

Note that the cut and paste functions of the window manager can also be used to duplicate ACL entries from ls -D to chacl.

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 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:

auditor:CAP_AUDIT_WRITE,CAP_AUDIT_CONTROL,CAP_KILL+eip

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.

You can create unique capabilities at your site. Simply add the capability tag you want (it must be unique) to your /etc/capability file on the line for the user or users who are to have the capability, then use the chcap(1) command to add the capability requirement to the files and directories you desire.

If you believe you have experienced corruption of some capability requirements on files or directories , you can use the attrinit(1) command to restore those capability requirements.

The /etc/irixcap file is used with the attrinit command as follows:

Log in as root and change directories to the / directory. Next, give the command:

attrinit -script=/etc/irixcap 

Your capability integrity will be restored. The process may take a few moments.