Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Security Services Oracle Solaris 10 1/13 Information Library |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
Enhancements to Machine Security in the Solaris 10 Release
Controlling Access to Machine Resources
Limiting and Monitoring Superuser
Configuring Role-Based Access Control to Replace Superuser
Preventing Unintentional Misuse of Machine Resources
Assigning a Restricted Shell to Users
Restricting Access to Data in Files
Restricting setuid Executable Files
Using the Automated Security Enhancement Tool
Using the Oracle Solaris Security Toolkit
Using the Secure by Default Configuration
Using Resource Management Features
Monitoring Use of Machine Resources
Protecting Files With Encryption
Restricting root Access to Shared Files
Authentication and Authorization for Remote Access
Encryption and Firewall Systems
3. Controlling Access to Systems (Tasks)
4. Controlling Access to Devices (Tasks)
5. Using the Basic Audit Reporting Tool (Tasks)
6. Controlling Access to Files (Tasks)
7. Using the Automated Security Enhancement Tool (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
Part IV Cryptographic Services
13. Oracle Solaris Cryptographic Framework (Overview)
14. Oracle Solaris Cryptographic Framework (Tasks)
15. Oracle Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
19. Using Secure Shell (Tasks)
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
24. Kerberos Error Messages and Troubleshooting
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Auditing in Oracle Solaris
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
30. Managing Oracle Solaris Auditing (Tasks)
In the workplace, all computers that are connected to a server can be thought of as one large multifaceted system. You are responsible for the security of this larger system. You need to defend the network from outsiders who are trying to gain access. You also need to ensure the integrity of the data on the computers within the network.
At the file level, Oracle Solaris provides standard security features that you can use to protect files, directories, and devices. At the system and network levels, the security issues are mostly the same. The first line of security defense is to control access to your system.
You can control and monitor system access by doing the following:
To control access to your system, you must maintain the physical security of your computing environment. For instance, a system that is logged in and left unattended is vulnerable to unauthorized access. An intruder can gain access to the operating system and to the network. The computer's surroundings and the computer hardware must be physically protected from unauthorized access.
You can protect a SPARC system from unauthorized access to the hardware settings. Use the eeprom command to require a password to access the PROM. For more information, see How to Require a Password for Hardware Access.
You also must prevent unauthorized logins to a system or the network, which you can do through password assignment and login control. All accounts on a system must have a password. A password is a simple authentication mechanism. An account without a password makes your entire network accessible to an intruder who guesses a user name. A strong password algorithm protects against brute force attacks.
When a user logs in to a system, the login command checks the appropriate naming service or directory service database according to the information that is listed in the /etc/nsswitch.conf file. This file can include the following entries:
files – Designates the /etc files on the local system
ldap – Designates the LDAP directory service on the LDAP server
nis – Designates the NIS database on the NIS master server
nisplus – Designates the NIS+ database on the NIS+ root server
For a description of the nsswitch.conf file, see the nsswitch.conf(4) man page. For information about naming services and directory services, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (NIS+).
The login command verifies the user name and password that were supplied by the user. If the user name is not in the password file, the login command denies access to the system. If the password is not correct for the user name that was specified, the login command denies access to the system. When the user supplies a valid user name and its corresponding password, the system grants the user access to the system.
PAM modules can streamline login to applications after a successful system login. For more information, see Chapter 17, Using PAM.
Sophisticated authentication and authorization mechanisms are available on Oracle Solaris systems. For a discussion of authentication and authorization mechanisms at the network level, see Authentication and Authorization for Remote Access.
When users log in to a system, they must supply both a user name and a password. Although logins are publicly known, passwords must be kept secret. Passwords should be known only to each user. You should ask your users to choose their passwords carefully. Users should change their passwords 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 administering passwords, see Chapter 4, Managing User Accounts and Groups (Overview), in Oracle Solaris Administration: Basic Administration and the passwd(1) man page.
If your network uses local files to authenticate users, 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 /etc/passwd file. 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 system, only superuser or an equivalent role can read the /etc/shadow file. You can use the passwd command to change a user's password on a local system.
If your network uses NIS to authenticate users, password information is kept in the NIS password map. NIS does not support password aging. You can use the command passwd -r nis to change a user's password that is stored in an NIS password map.
If your network uses NIS+ to authenticate users, password information is kept in the NIS+ database. Information in the NIS+ database can be protected by restricting access to authorized users only. You can use the passwd -r nisplus command to change a user's password that is stored in an NIS+ database.
The Oracle Solaris LDAP naming service stores password information and shadow information in the ou=people container of the LDAP directory tree. On the Oracle Solaris LDAP naming service client, you can use the passwd -r ldap command to change a user's password. The LDAP naming service stores the password in the LDAP repository.
Password policy is enforced on the Sun Java System Directory Server. Specifically, the client's pam_ldap module follows the password policy controls that are enforced on the Sun Java System Directory Server. For more information, see LDAP Naming Services Security Model in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Strong password encryption provides an early barrier against attack. Oracle Solaris software provides six password encryption algorithms. The Blowfish, MD5, and SHA algorithms provide more robust password encryption than the UNIX algorithm.
You specify the algorithms configuration for your site in the /etc/security/policy.conf file. In the policy.conf file, the algorithms are named by their identifier, as shown in the following table. For the identifier-algorithm mapping, see the /etc/security/crypt.conf file.
Table 2-1 Password Encryption Algorithms
|
The following shows the default algorithms configuration in the policy.conf file:
# … # crypt(3c) Algorithms Configuration # # CRYPT_ALGORITHMS_ALLOW specifies the algorithms that are allowed to # be used for new passwords. This is enforced only in crypt_gensalt(3c). # CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6 # To deprecate use of the traditional unix algorithm, uncomment below # and change CRYPT_DEFAULT= to another algorithm. For example, # CRYPT_DEFAULT=1 for BSD/Linux MD5. # #CRYPT_ALGORITHMS_DEPRECATE=__unix__ # The Solaris default is the traditional UNIX algorithm. This is not # listed in crypt.conf(4) since it is internal to libc. The reserved # name __unix__ is used to refer to it. # CRYPT_DEFAULT=__unix__ …
When you change the value for CRYPT_DEFAULT, the passwords of new users are encrypted with the algorithm that is associated with the new value.
When existing users change their passwords, how their old password was encrypted affects which algorithm is used to encrypt the new password. For example, assume that CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6, and CRYPT_DEFAULT=1. The following table shows which algorithm would be used to generate the encrypted password.
|
For more information on configuring the algorithm choices, see the policy.conf(4) man page. To specify password encryption algorithms, see Changing the Password Algorithm (Task Map).
The root account is one of several special system accounts. Of these accounts, only the root account is assigned a password and can log in. The nuucp account can log in for file transfers. The other system accounts either protect files or run administrative processes without using the full powers of root.
Caution - Never change the password setting of a system account. An account that is delivered with NP or *LK*sys in the second field of the shadow file indicates a system account. |
The following table lists some system accounts and their uses. The system accounts perform special functions. Each account has a UID that is less than 100.
Table 2-2 System Accounts and Their Uses
|
Remote logins offer a tempting avenue for intruders. Oracle Solaris provides several commands to monitor, limit, and disable remote logins. For procedures, see Securing Logins and Passwords (Task Map).
By default, remote logins cannot gain control or read certain system devices, such as the system mouse, keyboard, frame buffer, or audio device. For more information, see the logindevperm(4) man page.
When a computer can be accessed through a modem or a dial-up port, you can add an extra layer of security. You can require a dial-up password for users who access a system through a modem or dial-up port. A user must supply this additional password before being granted access to the system.
Only superuser can create or change a dial-up password. To ensure the integrity of the system, the password should be changed about once a month. The most effective use of this feature is to require a dial-up password to gain access to a gateway system. To set up dial-up passwords, see How to Create a Dial-Up Password.
Two files are involved in creating a dial-up password, /etc/dialups and /etc/d_passwd. The dialups file contains a list of ports that require a dial-up password. The d_passwd file contains a list of shell programs that require an encrypted password as the additional dial-up password. The information in these two files is processed as follows:
If the user's login shell in /etc/passwd matches an entry in /etc/d_passwd, the user must supply a dial-up password.
If the user's login shell in /etc/passwd is not found in /etc/d_passwd, the user must supply the default password. The default password is the entry for /usr/bin/sh.
If the login shell field in /etc/passwd is empty, the user must supply the default password. The default password is the entry for /usr/bin/sh.
If /etc/d_passwd has no entry for /usr/bin/sh, then those users whose login shell field in /etc/passwd is empty or does not match any entry in /etc/d_passwd are not prompted for a dial-up password.
Dial-up logins are disabled if /etc/d_passwd has the /usr/bin/sh:*: entry only.