File Security
The SunOS operating system is a multiuser system, which means that all the users who are logged in to a system can read and use files that belong to one another, as long as they have the file permissions to do so. Table 14-1 describes the commands for file system security. For step-by-step instructions on securing files, see Chapter 15, Securing Files (Tasks).
Commands for File System Security
This table describes the commands for monitoring and securing files and directories.
Table 14-1 Commands for File System Security
Command | Description | Man Page |
|---|---|---|
Lists the files in a directory and information about them. | ls(1) | |
Changes the ownership of a file. | chown(1) | |
Changes the group ownership of a file. | chgrp(1) | |
Changes permissions on a file. You can use either symbolic mode (letters and symbols) or absolute mode (octal numbers) to change permissions on a file. | chmod(1) |
File Encryption
By placing a sensitive file into an inaccessible directory (700 mode) and making the file unreadable by other users (600 mode), you will keep it secure in most cases. However, someone who guesses your password or the root password can read and write to that file. Also, the sensitive file is preserved on a backup tape every time you back up the system files to tape.
Fortunately, an additional layer of security is available to all SunOS system software users in the United States: the optional file encryption kit. The encryption kit includes the crypt command, which scrambles the data to disguise the text. For more information, see crypt(1).
Access Control Lists (ACLs)
ACLs (pronounced "ackkls") can provide greater control over file permissions when the traditional UNIX file protection in the SunOS operating system is not sufficient. The traditional UNIX file protection provides read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides better file security by enabling you to define file permissions for the owner, owner's group, others, specific users and groups, and to define default permissions for each of those categories. For step-by-step instructions on using ACLs, see "Using Access Control Lists (ACLs)".
The following table lists the commands for administering ACLs on files or directories.
Table 14-2 ACL Commands
Command | Description | Man Page |
|---|---|---|
setfacl | Sets, adds, modifies, and deletes ACL entries | setfacl(1) |
getfacl | Displays ACL entries | getfacl(1) |
System Security
This section describes how to safeguard your system against unauthorized access, such as the following:
How to prevent an intruder from logging in to your system
How to maintain the password files
How to prevent unauthorized superuser access to sensitive system files and programs
You can set up two security barriers on a system. The first security barrier is the login command. To cross this barrier and gain access to a system, a user must supply a user name and a corresponding password that is known by the local system or by the name service (LDAP, NIS, or NIS+).
The second security barrier is ensuring that the system files and programs can be changed or removed by superuser only. A would-be superuser must supply the root user name and its correct password.
Login Access Restrictions
When a user logs in to a system, the login command consults the appropriate database according to the information that is listed in the /etc/nsswitch.conf file. The entries in this file can include files (which designates the /etc files), nis (which designates the NIS database), ldap (which designates the LDAP directory service), and nisplus (which designates the NIS+ database). For a description of this file, see the nsswitch.conf(4) man page. For information about naming or directory services, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or System Administration Guide: Naming and Directory Services (FNS and NIS+).
The login command verifies the user name and password that were entered. If the user name is not in the password file or the password is not correct for the user name, the login command denies access to the system. When the user supplies a user name from the password file and the correct password for the user name, the system grants the user access to the system.
Special Logins
There are two common ways to access a system: by using a conventional user login, or by using the root login. In addition, a number of special system logins allow a user to perform administrative commands without using the root account. The administrator assigns passwords to these login accounts.
The following table lists some system login accounts and their uses. The system logins perform special functions, and each login has its own group identifier number (GID). Each of these logins should have its own password, which should be distributed on a need-to-know basis.
Table 14-3 System Logins
Login Account | GID | Use |
|---|---|---|
root | 0 | Has almost no restrictions and overrides all other logins, protections, and permissions. The root account has access to the entire system. The password for the root login should be very carefully protected. The root account owns most of the Solaris commands. |
daemon | 1 | Controls background processing. |
bin | 2 | Owns some of the Solaris commands. |
sys | 3 | Owns many system files. |
adm | 4 | Owns certain administrative files. |
lp | 71 | Owns the object data files and spooled data files for the printer. |
uucp | 5 | Owns the object data files and spooled data files for UUCP, the UNIX-to-UNIX copy program. |
nuucp | 9 | Is used by remote systems to log in to the system and start file transfers. |
You should also set the security of the eeprom command to require a password. See eeprom(1M) for more information.
Managing Password Information
When users log in to a system, they must enter both a user name and a password. Although logins are publicly known, passwords must be kept secret, known only to each user. You should ask your users to choose their passwords carefully, and they should change them often.
Passwords are initially created when you set up a user account. To maintain security on user accounts, you can set up password aging to force users to routinely change their passwords. You can also disable a user account by locking the password. For detailed information about setting up and maintaining passwords, see "Managing User Accounts and Groups (Overview)" in System Administration Guide: Basic Administration and the passwd(1) man page.
NIS+ Password File
If your network uses NIS+, the password information is kept in the NIS+ database. Information in the NIS+ database can be protected by restricting access to authorized users. You can use the passwd command to change a user's NIS+ password.
NIS Password File
If your network uses NIS, the password information is kept in the NIS password map. NIS does not support password aging. You can use the passwd command to change a user's NIS password.
/etc Files
If your network uses /etc files, the password information is kept in the system's /etc/passwd and /etc/shadow files. The user name and other information are kept in the password file /etc/passwd, while the encrypted password itself is kept in a separate shadow file, /etc/shadow. This security measure prevents a user from gaining access to the encrypted passwords. While the /etc/passwd file is available to anyone who can log in to a machine, only superuser can read the /etc/shadow file. You can use the passwd command to change a user's password on a local system.
LDAP Password Information
If your network uses LDAP, the password and shadow information is stored in the ou=people container of the LDAP directory tree. You can use the password -r ldap command to change a user's LDAP password.
Using the Restricted Shell
The standard shell allows a user to open files, execute commands, and so on. The restricted shell (rsh) can be used to limit the ability of a user to change directories and execute commands. The restricted shell is located in the /usr/lib directory. Note that the restricted shell is not the remote shell, which is /usr/sbin/rsh. The restricted shell differs from the standard shell in these ways:
The user is limited to the home directory, so the user cannot use the cd command to change directories.
The user can use only commands in the PATH set by the system administrator, so the user cannot change the PATH variable.
The user can access only files in the home directory and its subdirectories, so the user cannot name commands or files by using a complete path name.
The user cannot redirect output with > or >>.
The restricted shell allows the system administrator to limit a user's ability to stray into the system files, and is intended mainly to set up a user who needs to perform specific tasks. The restricted shell is not completely secure, however, and is only intended to keep unskilled users from getting into (or causing) trouble.
For information about the restricted shell, see the rsh(1M) man page.
A more secure alternative to the restricted shell is the Secure Shell (ssh), which enables users to securely access a remote host over an unsecured network. For information about using the Secure Shell, see Chapter 5, Secure Shell Administration (Reference).