Access control allows administrators to set up policies and accounts that allow each user 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.
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) provide a finer granularity of control than provided by the traditional permission bits.
The Commercial Security Pak 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 the following command at your system prompt in any directory:
ls -l |
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, 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 something like this:
-rw-r--r-- |
Each character is significant in the permissions listing. 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 an ordinary file, a 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 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 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.”
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.
Here is a long listing of a 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 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 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 you to maintain security and still allow convenient access to your files. To set up your account to allow group read and write privileges and no other privileges, place this line in your .cshrc or .profile file:
umask 007 |
This makes 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 other words, you will have full use of the file or directory, and your group will have full use. No other user, except the Superuser (root), has access to your files.
Access Control Lists (ACLs) are a part of the Discretionary Access Control Features of your Commercial Security Pak 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 subdirectories 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 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, it also applies 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 in this example:
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 in the first entry on the line, sets read permission for user ID 332 in 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 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 letters in the following order. Any or all of these may be replaced by the no access character (a dash):
r
w
x
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 (the first entry on the line) sets read permission for user ID 332 in 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 letters 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 privileges assigned to specific accounts to allow those accounts to perform operations formerly reserved for the superuser (root). To maintain the principle of least privilege, the capabilities of the superuser account have been subdivided into various capabilities, which can be assigned to separate individual accounts. The corresponding capability is placed on sensitive executable files and programs on your system. The account capability and the executable capability must be compatible for the user to execute the program. For a more technical discussion, see the capabilities(4) reference page or Chapter 4 of the Commercial Security Pak Administrator's Guide.
The fundamental purpose of capabilities is to allow administrators to perform system administration from standard login accounts without requiring the use of superuser or other sorts of privileged accounts. A capability may be granted to any user account, and a corresponding capability attached to only those system objects that the owner of the account has a legitimate need to use. This follows the trusted systems principle of least privilege—using the lowest possible promotion of privileges necessary to get the job done. Capabilities implement least privilege both by limiting the number of users privileged to perform various tasks and by limiting the privilege to just that program, or section of code within a program, necessary to perform the proper action.
This section describes the password mechanisms of the Commercial Security Pak. Passwords are the first line of defense of a trusted system. As a user, it is your responsibility to protect the privacy of your password at all times. Follow these rules when dealing with your password:
Never give your password to another user, or allow another user to “borrow” your account.
Never keep your password written down anywhere near your system.
Always commit your password to memory. If you forget it, the Administrator can change it for you.
The Commercial Security Pak contains facilities to generate passwords for users and these facilities are configured to work by default. If your site has changed the configuration to allow you to select your own passwords, follow these rules when choosing your password:
Never choose a password that could be guessed by someone who knows personal information about you. For example, if someone steals your wallet with the intent of finding out information about you, make certain that your password is not anything related to something someone might find in your personal information, such as variations on your name or the name of a friend or family member.
Always use a random mix of printable characters, control characters, punctuation marks, and numerals when selecting a password.
Each password must have at least six characters. However, only the first eight characters are significant.
The password must contain at least two alphabet characters and one numeral character.
The password must not be related to the user's login name. Any reversing or circular shift of the characters in the login name is not allowed. For the purposes of this test, capital letters are assumed to be equivalent to their lowercase counterparts.
The password must have at least three characters difference from the previous password. For the purposes of this test, capital letters are assumed to be equivalent to their lowercase counterparts.
The Commercial Security Pak supports mandatory password generation. The default generator presents the user with five selected passwords, and the user is free to accept or reject any of these. If the user does not accept any of the offered passwords, he or she may press the Enter key and the system presents a new set of password choices.
IRIX supports password aging. Password aging is defined as being able to set a minimum and maximum lifetime for passwords. Password aging is a very useful feature. By limiting the amount of time a password may be in use, you limit the amount of time a potential intruder has to crack your password. By enforcing a minimum lifetime, you prevent lazy users from simply changing their password briefly and then returning to their usual password immediately.
If a user does not change the password within the specified time period, the account is automatically locked. Any user can place the following line in their .login or /.profile files to show notification when password expiration is imminent:
showpwage username |
By default, showpwage(1) notifies the user only if the password is within seven days of expiration. This default can be changed with the -d flag. See the showpwage(1) reference page for a complete description of this command.
Generally, the only time that an account becomes locked is when the user is away for an extended period of time. But once locked, an account can be unlocked only by the superuser. The user should choose a new password the next time he or she logs in.