Controlling Access to a Computer System
In the workplace, all machines 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 to the network. You also need to ensure
the integrity of the data on the machines within the network.
At the file level, the Solaris OS 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:
Maintaining Physical Security
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
should 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.
Maintaining Login Control
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 should 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 name 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 Solaris systems. For a discussion
of authentication and authorization mechanisms at the network level, see Authentication and Authorization for Remote Access.
Managing Password Information
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 System Administration Guide: Basic Administration and the
passwd(1) man page.
Local Passwords
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 password file /etc/passwd. 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.
NIS and NIS+ Passwords
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.
LDAP Passwords
The Solaris LDAP naming service stores password information and shadow information in the
ou=people container of the LDAP directory tree. On the 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.
In the Solaris 10 release, password policy is enforced on the Sun
JavaTM 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).
Password Encryption
Strong password encryption provides an early barrier against attack. Solaris software provides four
password encryption algorithms. The two MD5 algorithms and the Blowfish algorithm provide more robust password
encryption than the UNIX algorithm.
Password Algorithm Identifiers
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.
Table 2-1 Password Encryption Algorithms
Identifier |
Description |
Algorithm Man Page |
|---|
1 |
The MD5 algorithm that is compatible with
MD5 algorithms on BSD and Linux systems. |
crypt_bsdmd5(5) |
2a |
The Blowfish algorithm that is compatible with
the Blowfish algorithm on BSD systems. |
crypt_bsdbf(5) |
md5 |
The Sun MD5 algorithm, which is considered stronger
than the BSD and Linux version of MD5. |
crypt_sunmd5(5) |
__unix__ |
The traditional UNIX encryption algorithm. This
algorithm is the default module in the policy.conf file. |
crypt_unix(5) |
Algorithms Configuration in the policy.conf File
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
# 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
current 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 and CRYPT_DEFAULT=1. The following table shows which
algorithm would be used to generate the encrypted password.
Identifier = Password Algorithm |
Explanation |
|---|
Initial Password |
Changed
Password |
|---|
1 = crypt_bsdmd5 |
Uses same algorithm |
The 1 identifier is also the value of
CRYPT_DEFAULT. The user's password continues to be encrypted with the crypt_bsdmd5 algorithm. |
2a
= crypt_bsdbf |
Uses same algorithm |
The 2a identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore,
the new password is encrypted with the crypt_bsbdf algorithm. |
md5 = crypt_md5 |
Uses same
algorithm |
The md5 identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password
is encrypted with the crypt_md5 algorithm. |
__unix__ = crypt_unix |
Uses crypt_bsdmd5 algorithm |
The __unix__ identifier
is not in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the crypt_unix algorithm cannot be used.
The new password is encrypted with the CRYPT_DEFAULT algorithm. |
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).
Special System Logins
Two common ways to access a system are by using a conventional user
login, or by using the root login. In addition, a number of special
system logins enable a user to run administrative commands without using the root
account. As system administrator, you assign passwords to these login accounts.
The following table lists some system login accounts and their uses. The system logins
perform special functions. Each login has its own group identification number (GID). Each
login should have its own password, which should be divulged on a need-to-know
basis.
Table 2-2 System Login Accounts and Their Uses
Login Account |
GID |
Use |
|---|
root |
0 |
Has almost no restrictions. 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, superuser,
owns most of the Solaris commands. |
daemon |
1 |
Controls background processing. |
bin |
2 |
Owns some 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. |
Remote Logins
Remote logins offer a tempting avenue for intruders. The Solaris OS 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.
Dial-Up Logins
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.
The dial-up password is an additional password that a user must supply before
being granted access to the system.
Only superuser or a role of equivalent capabilities 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.
