Controlling and Monitoring System Access
Now that you understand file system structure, it's time to learn how to protect your files. It's difficult to overestimate the importance of security on your Solaris computer or network. Critical data has a variety of forms. If compromised, some files could leak trade secrets, giving competitors an unfair advantage. Other files could cause legal hassles if exposed. In any case, you need to control access to your computer systems.
The first step to control system access is physical. If someone can get to your machine, they can either read sensitive data or use brute force to destroy data. The second step, one that we have talked about, is making sure that users have good passwords and change them frequently. The last step is setting up proper permissions, so the users who do log in to your network have the appropriate level of file access. This section covers the final step.
File and Directory Permissions
Solaris, like most other UNIX-based operating systems, categorizes users into three classes when it comes to resource access: the owner of the file (owner or user), a member of the group the owner belongs to (group), and everyone else (other). The basic set of UNIX permissions allows for three distinct operations on a given file: Read, Write, and Execute. Each class and permission combination is considered separately. That is, the owner can have Read, Write, and Execute permissions on a file, whereas everyone else (other) can be denied access to the same file.
| Note | The owner of the file and the superuser are the only two users who can modify permissions on a file. Regardless of permissions set on a file, the superuser always has Read, Write, and Execute privileges on every file. |
Before we look at displaying and changing permissions, let's clarify what is meant by Read, Write, and Execute. Table 5.4 breaks down the permissions and how they affect what designated users can do to files and directories.
| Permission | File Consequences | Directory Consequences |
|---|---|---|
| Read (r) | Can open and read the contents of the file | Can list files in the directory |
| Write (w) | Can modify or delete the file | Can add or remove files or links in the directory |
| Execute (x) | Can execute the program | Can open and execute files in the directory, and can make the directory and subdirectories under it current |
| None (-) | Cannot read, write, or execute the file | Cannot list, add, remove, or execute files in the directory |
| Warning | Giving someone Write permissions gives them the ability to delete! |
Displaying and Changing Permissions
Permissions are displayed when you use ls -l to show a long directory listing. Here's an example to refresh your memory:
$ ls -l total 4 drwxrwxr-x 2 qdocter author 512 Aug 10 11:23 docs -rw-r--r-- 1 qdocter author 80 Aug 10 11:44 file1
Because we're discussing permissions, the only parts of the directory listing you need to be concerned with right now are the first 10 characters and the name of the file. The first character indicates that the file is either a special type of file or a regular file. The first file listed in our example is a directory, as indicated by the lowercase d. The second file, named file1, is a regular file, as indicated by the dash preceding the permissions.
The following nine characters define permissions for that file. The first grouping of three letters (rwx) defines permissions for the owner, the second cluster is for group permissions, and the last tier is for other. In our example, the docs directory has Read, Write, and Execute permissions set for the owner and group, and Read and Execute set for other. The file1 file has Read and Write for the owner, and Read-only for group and other.
The chmod command is used to set permissions on files. This command functions in two modes: symbolic mode and absolute mode.
Symbolic Mode
When using chmod in symbolic mode, letters designate both whom the permissions will impact and the permissions to effect. The syntax for chmod in symbolic mode is as follows:
$ chmod options who operator permission file
For example, the command:
$ chmod o+w file21
will add Write permission to the owner for file21. To specify multiple groups, separate the who, operator, and permission grouping with commas, such as:
$ chmod o+w,g+r file21
There are four options for the who variable. To set user (owner) permissions, use u. group permissions are set with g, other permissions with o, and all permissions (owner, group, and other) are set with a.
| Note | When using symbolic mode to change permissions, remember that o means other, not owner. For owner permissions, use u. Failure to use the proper codes could result in serious security holes. |
The operator variable tells chmod what to do with the permissions specified. There are three options for the operator: a + tells chmod to add the permission to existing permissions, a- removes permissions, and an = sets the permissions to exactly what is specified. If the = is used and no permissions are specified, then all permissions for the specified who are cleared.
There are 10 options for the permission variable. They are described in Table 5.5.
| Letter | Description |
|---|---|
| r | Sets Read permission |
| w | Sets Write permission |
| x | Sets Execute permission |
| l | Enables mandatory locking |
| s | SetUID/SetGID, depending on who is specified by the who variable |
| t | Enables the sticky bit |
| X | Execute permission if the file is a directory or if there is execute permission for one of the other user classes. |
| u | Sets the permissions to those already present for the owner |
| g | Sets the permissions to those already present for the group |
| o | Sets the permissions to those already present for others |
This can be a lot to absorb; some examples might help.
$ ls -l total 3 -rwxrwxr-x 2 qdocter author 874 Aug 10 11:23 textfile
For the preceding file, you want to remove the Write permissions for the group. Here's how to do that:
$ chmod g-w textfile $ ls -l total 3 -rwxr-xr-x 2 qdocter author 874 Aug 10 11:23 textfile
If you read the chmod command literally, it says, "For group permissions, remove Write on textfile." This next example removes execute permissions for both group and other:
$ chmod go-x textfile $ ls -l total 3 -rwxr--r-- 2 qdocter author 874 Aug 10 11:23 textfile
Now, members of the author group and everyone else have only Read permission to textfile. To quickly clear all permissions from the file, you could use the following:
$ chmod a= textfile $ ls -l total 3 ---------- 2 qdocter author 874 Aug 10 11:23 textfile
One final example:
$ ls -l total 3 -rwx------ 2 qdocter author 874 Aug 10 11:23 textfile $ chmod go=u textfile $ ls -l total 3 -rwxrwxrwx 2 qdocter author 874 Aug 10 11:23 textfile
As with everything else in the computer world, playing around with permissions (on a test system, please) is the best way to learn what you can and cannot do. For example, the s permission works only with a who of u or g, and t works only with u.
Absolute Mode
Instead of using letter designations to assign permissions, some administrators prefer to use chmod in absolute mode. Absolute mode enables you to assign permissions by using an octal representation instead of a user, operator, and permission code. The numerical values for all permissions are listed in Table 5.6.
| Number | Description |
|---|---|
| 4000 | Enables SetUID |
| 20n0 | Enables SetGID when the value of n is odd, or else enables mandatory locking |
| 1000 | Sets the sticky bit |
| 0400 | Sets owner permissions to Read |
| 0200 | Sets owner permissions to Write |
| 0100 | Sets owner permissions to Execute |
| 0040 | Sets group permissions to Read |
| 0020 | Sets group permissions to Write |
| 0010 | Sets group permissions to Execute |
| 0004 | Sets other permissions to Read |
| 0002 | Sets other permissions to Write |
| 0001 | Sets other permissions to Execute |
To use absolute mode, you add the numbers together to achieve your desired result. (Some die-hard administrators call this ORing the numbers.) For example, if you want to grant the owner Read, Write, and Execute permissions, and the group Read-only, you would use chmod 740 filename (the value 740 was obtained by adding 400 + 200 + 100 + 40). Perhaps the biggest philosophical difference between symbolic and absolute modes is that with symbolic mode, you often think in terms of adding or subtracting permissions. In absolute mode, you need to think in terms of net result: what do you want the final permissions to be?
| Tip | Unless you are specifying SetUID or SetGID, or enabling the sticky bit, you can use a three-digit number to specify permissions. |
As with symbolic mode, let's use some examples to clarify:
$ ls -l total 3 -rwxrwxr-x 2 qdocter author 874 Aug 10 11:23 textfile
For the preceding file, you want to remove the Write permissions for the group. Here's how to do that in absolute mode:
$ chmod 755 textfile $ ls -l total 3 -rwxr-xr-x 2 qdocter author 874 Aug 10 11:23 textfile
Again, when you use absolute mode, you need to think in terms of end result. Removing Write permissions for the group means that your second number (group) is going to be 5 (read-4, and execute-1). In the following example, you remove Execute permissions for both group and other:
$ chmod 744 textfile $ ls -l total 3 -rwxr--r-- 2 qdocter author 874 Aug 10 11:23 textfile
Now, members of the author group and everyone else have only Read permission to textfile. If you want to clear all permissions for the file, you can use the following:
$ chmod 000 textfile $ ls -l total 3 ---------- 2 qdocter author 874 Aug 10 11:23 textfile
You might have noticed that I used the same examples in absolute mode as I did in symbolic mode. No, it isn't because cutting and pasting is less work than thinking of new examples. It is to show that you can perform the exact same permissions modifications with either method. Although it's an excellent idea to be familiar with both methods (especially for the test), it's likely that you'll prefer one to the other and you'll use that method almost exclusively.
 |
You have been the systems administrator at your company for just over a year. In that time, you have convinced management to upgrade all servers to Solaris 9, and most of your workstations have been upgraded as well. Since you started working at the company, the number of client machines has grown from about 50 to well over 300. The company is growing quickly, and you are the only network administrator!
One of your biggest problems has been keeping track of security. You have set up good security measures and have educated users on secure operational procedures. However, you find that every once in a while, something slips by you, and you worry that your network security might someday be compromised. You need something or someone to help you out, but the IT budget does not provide for another network administrator.
You might want to consider using the Automated Security Enhancement Tool (aset). This tool is a set of security utilities shipped standard with Solaris 9. It can automate security settings, including checking permissions and ownership on system files, verifying system file contents, checking the integrity of the /etc/passwd and /etc/group files, and examining environment initialization files. Not only that, but aset can be set to run periodically and to e-mail a report to any user specified. The aset tool is capable of detecting possible security holes and fixing security problems as well.
Another useful feature of aset is that it has three security levels: low, medium, and high. You can use the level that most closely matches your network's security needs. Start using aset and you will find your security burden eased significantly. For more information, type man aset.
|
SetUID and SetGID
When an application with SetUID (Set User ID) is opened, the executing process assumes the privileges of the owner of that application. Similarly, if the SetGID bit is enabled, the executing process will assume the identity of the group owner for execution of the process. This can be both a good and a bad thing.
Say there is a program that you need to run to perform your weekly job duties. This program deletes all temporary files from the system and cleans up any outdated log files and print spool files. Unfortunately, deleting these files requires that you have superuser privileges, which you don't have. By enabling SetUID, when you (or anyone else for that matter) execute this cleanup program, you will assume the identity of the superuser (we're assuming that root is the owner of the application) in order to carry out the program. When the program is completed, you will no longer have any superuser rights.
This functionality can be extremely handy. Essentially, you, the administrator, can give users the ability to run applications that might require more access to resources than they would normally have. And this can be done without giving them the root password or adding them to the sysadmin group.
Of course, any time you give regular users superuser privileges, you run the risk of a security breach. Consequently, you should be very, very careful about the use of SetUID and SetGID. Most applications don't require their use, and you should closely monitor those that do. In fact, many companies won't run software that requires enabling SetUID or SetGID.
SetUID and SetGID are enabled through the chmod command. The following example shows two files. The first one (app1) has SetUID enabled, and the second one (app2) has SetGID enabled (look for the s):
$ ls -l -rwsr-xr-x 2 qdocter author 38604 Aug 10 11:23 app1 -rwxr-sr-x 1 qdocter author 19124 Aug 10 11:44 app2
SetUID and SetGID can be very useful but also pose an incredibly dangerous inherent security risk.
| Note | You cannot set or clear the SetGID bit for directories in absolute mode. It must be set or cleared in symbolic mode by using g+s or g-s. You can set and clear the SetGID bit for files in absolute mode. |
Sticky Bit
A sticky bit is used to prevent the deletion of files in public directories. After the sticky bit is set on a directory, the only people who can delete or rename files in the directory are the owner of the file, the owner of the directory, or the superuser. Sticky bits are particularly useful in public directories, where users might have the opportunity to maliciously (or accidentally) delete common files.
When the sticky bit is set, a T or t will appear in the directory's other Execute permission slot. If the execution bit for others is off, a capital T will appear. If the execution bit for others is on, it will be a lowercase t. Here's an example:
$ chmod 1745 bookdir $ ls -l total 3 drwxr--r-t 2 qdocter author 874 Aug 11 14:20 bookdir $ chmod 1744 bookdir $ ls -l total 3 drwxr--r-T 2 qdocter author 874 Aug 11 14:20 bookdir
| Note | The sticky bit can be set through absolute mode or symbolic mode. |
umask
When a new file is created in Solaris, the default permissions are 666 (Read and Write for all), and when a directory is created, the default permissions are 777 (Read, Write, and Execute for all). These default permissions are modified by the umask specified in either the user's initialization file or a global initialization file.
The default umask is 022. When new files are created, the umask value is subtracted from the default (full access) values, thereby restricting (masking) permissions. Therefore, with a default umask, new directories will have effective permissions of 755 (777 - 022), giving the owner Read, Write, and Execute, and giving the group and other Read and Execute. Newly created files will have permissions of 644.
To display your current umask or to change your current umask value, use the umask command:
$ umask 022 $ umask 077 $ umask 077
| Note | If you change your umask with the umask command, it will default back to the mask specified in your initialization file after you log out and back in. To permanently change your umask, you must modify your initialization file. |
To increase security on your network, you can make the umask more restrictive. Many companies prefer a umask setting of 077 or 027.
| Note | The Korn shell supports symbolic mode arguments with the umask -S command, but the Bourne and C shells do not. |
Access Control Lists and Role Based Access Control
During the initial development stages of UNIX, the basic permission structure was sufficient for most users' needs. However, with increased networking capabilities and more extensive computer use, the existing permission structure became a bit limited. For example, you could set permissions for the owner of the file, but how would you set permissions for another user who might or might not be part of the owner's group? Security issues such as this became difficult to deal with. Access Control Lists (ACLs) were developed to enhance security flexibility.
Another security issue is the assignment of administrative duties. Suppose that you want one of your users to be able to reset user passwords or to back up files they might otherwise not be able to access. One option is to give the user the root password, but this solution screams, "Security hole!" Role Based Access Control (RBAC) enables you to create a role, which is like a user account, and assign the role certain administrative tasks. Then, a logged-in user can assume a role for temporary administrative purposes and still not have more access than they need.
ACLs and RBAC are vital big-picture security concepts in Solaris. But because ACLs and RBAC are not tested until the second Solaris Certified System Administrator exam, they don't need to be covered in depth at this time. They are covered extensively in Chapter 13, "Advanced Security Concepts."
|
|
EAN: 2147483647
Pages: 194