This section covers security that can be configured on a non-networked system. The chapters discuss planning, monitoring, and controlling access to the disk, to files, and to peripheral devices.
Keeping a machine's information secure is an important system administration responsibility. This chapter provides overview information about managing machine security.
The following is a list of the overview information in this chapter.
Since the Solaris 9 release, the following features have been introduced to enhance system security:
Strong password encryption is available and configurable. For more information, see Password Encryption.
Device policy is enforced with privileges. For more information, see Device Policy (Overview).
For device allocation, the /etc/security/dev directory might not be supported in future releases of the Solaris OS.
The Basic Audit Reporting Tool (BART) can monitor the authenticity of the files on your system. For more information, see Chapter 5, Using the Basic Audit Reporting Tool (Tasks).
Files can be protected with strong encryption. For more information, see Protecting Files With Encryption.
Privileges enforce process rights at the kernel level. For more information, see Privileges (Overview).
The Solaris Cryptographic Framework centralizes cryptographic services for providers and for consumers. For more information, see Chapter 13, Solaris Cryptographic Framework (Overview).
The PAM framework provides functionality for many programs, such as Solaris Secure Shell. For more information, see Changes to PAM for the Solaris 10 Release.
Solaris zones and resource management control access to machine resources. For more information, see System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
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:
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.
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.
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.
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.
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 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.
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. Solaris software provides four password encryption algorithms. The two MD5 algorithms and the Blowfish algorithm 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.
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 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,5,6 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. |
5 = crypt_sha256 |
Uses same algorithm |
The 5 identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password is encrypted with the crypt_sha256 algorithm. |
6 = crypt_sha512 |
Uses same algorithm |
The 6 identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password is encrypted with the crypt_sha512 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).
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 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.
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.
Peripheral devices that are attached to a computer system pose a security risk. Microphones can pick up conversations and transmit them to remote systems. CD-ROMs can leave their information behind for reading by the next user of the CD-ROM device. Printers can be accessed remotely. Devices that are integral to the system can also present security issues. For example, network interfaces such as hme0 are considered integral devices.
Solaris software provides two methods of controlling access to devices. Device policy restricts or prevents access to devices that are integral to the system. Device policy is enforced in the kernel. Device allocation restricts or prevents access to peripheral devices. Device allocation is enforced at user allocation time.
Device policy uses privileges to protect selected devices in the kernel. For example, the device policy on network interfaces such as hme requires all privileges for reading or writing.
Device allocation uses authorizations to protect peripheral devices, such as printers or microphones. By default, device allocation is not enabled. Once enabled, device allocation can be configured to prevent the use of a device or to require authorization for access to the device. When a device is allocated for use, no other user can access the device until the current user deallocates it.
A Solaris system can be configured in several areas to control access to devices:
Set device policy – In the Solaris OS, you can require that the process that is accessing a particular device be running with a set of privileges. Processes without those privileges cannot use the device. At boot time, Solaris software configures device policy. Third-party drivers can be configured with device policy during installation. After installation, you, as the system administrator can add device policy to a device.
Make devices allocatable – When you enable device allocation, you can restrict the use of a device to one user at a time. You can further require that the user fulfill some security requirements. For example, you can require that the user be authorized to use the device.
Prevent devices from being used – You can prevent the use of a device, such as a microphone, by any user on a computer system. A computer kiosk might be a good candidate for making certain devices unavailable for use.
Confine a device to a particular zone – You can assign the use of a device to a non-global zone. For more information, see Device Use in Non-Global Zones in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones. For a more general discussion of devices and zones, see Configured Devices in Zones in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
The device policy mechanism enables you to specify that processes that open a device require certain privileges. Devices that are protected by device policy can only be accessed by processes that are running with the privileges that the device policy specifies. The Solaris OS provides default device policy. For example, network interfaces such as hme0 require that the processes that access the interface be running with the net_rawaccess privilege. The requirement is enforced in the kernel. For more information about privileges, see Privileges (Overview).
In earlier Solaris OS releases, device nodes were protected by file permissions alone. For example, devices owned by group sys could be opened only by members of group sys. Now, file permissions do not predict who can open a device. Instead, devices are protected with file permissions and with device policy. For example, the /dev/ip file has 666 permissions. However, the device can only be opened by a process with the appropriate privileges.
The configuration of device policy can be audited. The AUE_MODDEVPLCY audit event records changes in device policy.
For more information about device policy, see the following:
The device allocation mechanism enables you to restrict access to a peripheral device, such as a CD-ROM. You manage the mechanism locally. If device allocation is not enabled, peripheral devices are protected only by file permissions. For example, by default, peripheral devices are available for the following uses:
Any user can read and write to a diskette or CD-ROM.
Any user can attach a microphone.
Any user can access an attached printer.
Device allocation can restrict a device to authorized users. Device allocation can also prevent a device from being accessed at all. A user who allocates a device has exclusive use of that device until the user deallocates the device. When a device is deallocated, device-clean scripts erase any leftover data. You can write a device-clean script to purge information from devices that do not have a script. For an example, see Writing New Device-Clean Scripts.
Attempts to allocate a device, deallocate a device, and list allocatable devices can be audited. The audit events are part of the ot audit class.
For more information on device allocation, see the following:
As system administrator, you can control and monitor system activity. You can set limits on who can use what resources. You can log resource use, and you can monitor who is using the resources. You can also set up your machines to minimize improper use of resources.
Your system requires a root password for superuser access. In the default configuration, a user cannot remotely log in to a system as root. When logging in remotely, a user must log in with the user's user name and then use the su command to become root. You can monitor who has been using the su command, especially those users who are trying to gain superuser access. For procedures that monitor superuser and limit access to superuser, see Monitoring and Restricting Superuser (Task Map).
Role-based access control, or RBAC, is designed to limit the capabilities of superuser. Superuser, the root user, has access to every resource in the system. With RBAC, you can replace root with a set of roles with discrete powers. For example, you can set up one role to handle user account creation, and another role to handle system file modification. When you have established a role to handle a function or set of functions, you can remove those functions from root's capabilities.
Each role requires that a known user log in with their user name and password. After logging in, the user then assumes the role with a specific role password. As a consequence, someone who learns the root password has limited ability to damage your system. For more on RBAC, see Role-Based Access Control (Overview).
You can prevent you and your users from making unintentional errors in the following ways:
You can keep from running a Trojan horse by correctly setting the PATH variable.
You can assign a restricted shell to users. A restricted shell prevents user error by steering users to those parts of the system that the users need for their jobs. In fact, through careful setup, you can ensure that users access only those parts of the system that help the users work efficiently.
You can set restrictive permissions on files that users do not need to access.
You should take care to correctly set the PATH variable. Otherwise, you can accidentally run a program that was introduced by someone else. The intruding program can corrupt your data or harm your system. This kind of program, which creates a security hazard, is referred to as a Trojan horse. For example, a substitute su program could be placed in a public directory where you, as system administrator, might run the substitute program. Such a script would look just like the regular su command. Because the script removes itself after execution, you would have little evidence to show that you have actually run a Trojan horse.
The PATH variable is automatically set at login time. The path is set through the startup files: .login, .profile, and .cshrc. When you set up the user search path so that the current directory (.) comes last, you are protected from running this type of Trojan horse. The PATH variable for superuser should not include the current directory at all.
The Automated Security Enhancement Tool (ASET) examines the startup files to ensure that the PATH variable is set up correctly. ASET also ensures that the PATH variable does not contain a dot (.) entry.
The standard shell allows a user to open files, execute commands, and so on. The restricted shell limits the ability of a user to change directories and to execute commands. The restricted shell is invoked with the /usr/lib/rsh command. Note that the restricted shell is not the remote shell, which is /usr/sbin/rsh.
The restricted shell differs from the standard shell in the following ways:
The user is limited to the user's home directory, so the user cannot use the cd command to change directories. Therefore, the user cannot browse system files.
The user cannot change the PATH variable, so the user can use only commands in the path that is set by the system administrator. The user also cannot execute commands or scripts by using a complete path name.
The restricted shell enables you to limit a user's ability to stray into system files. The shell creates a limited environment for 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 inadvertently doing damage.
For information about the restricted shell, use the man -s1m rsh command to see the rsh(1M) man page.
Because the Solaris OS is a multiuser environment, file system security is the most basic security risk on a system. You can use traditional UNIX file protections to protect your files. You can also use the more secure access control lists (ACLs).
You might want to allow some users to read some files, and give other users permission to change or delete some files. You might have some data that you do not want anyone else to see. Chapter 6, Controlling Access to Files (Tasks) discusses how to set file permissions.
Executable files can be security risks. Many executable programs have to be run as root, that is, as superuser, to work properly. These setuid programs run with the user ID set to 0. Anyone who is running these programs runs the programs with the root ID. A program that runs with the root ID creates a potential security problem if the program was not written with security in mind.
Except for the executables that Sun ships with the setuid bit set to root, you should disallow the use of setuid programs. If you cannot disallow the use of setuid programs, then you should at least restrict their use. Secure administration requires few setuid programs.
For more information, see Preventing Executable Files From Compromising Security. For procedures, see Protecting Against Programs With Security Risk (Task Map).
The ASET security package provides automated administration tools that enable you to control and monitor your system's security. ASET provides three security levels: low, medium, and high. You specify an ASET security level. At each higher level, ASET's file-control functions increase to reduce file access and tighten your system's security. For more information, see Chapter 7, Using the Automated Security Enhancement Tool (Tasks).
While ASET can be used to make a small number of security changes to a system, the Sun Security Toolkit provides a flexible and extensible mechanism to minimize, harden, and secure a Solaris system. The Sun Security Toolkit, informally known as the JASS toolkit, is a tool that enables the user to perform security modifications to a system. The tool can provide a report on the security status of a system. The tool also has the ability to undo previous runs of the tool. The JASS toolkit can be downloaded from the Sun web site, http://www.sun.com/software/security/jass. The web site contains pointers to online documentation.
The toolkit is described in detail in Securing Systems with the Solaris Security Toolkit, by Alex Noordergraaf and Glenn Brunette, ISBN 0-13-141071-7, June 2003. The book is part of the Sun BluePrints Series, which is published by Sun Microsystems Press.
By default, when the Solaris 10 release is installed, a large set of network services are enabled. To limit a system's network connectivity, you run the netservices limited command. This command activates a “Secure by Default” (SBD) configuration. With SBD, the only network service that accepts network requests is the sshd daemon. All other network services are disabled or handle local requests only. To enable individual network services, such as ftp, you use the Solaris Service Management Facility (SMF). For more information, see the netservices(1M) and smf(5) man pages.
Solaris software provides sophisticated resource management features. Using these features, you can allocate, schedule, monitor, and cap resource use by applications in a server consolidation environment. The resource controls framework enables you to set constraints on system resources that are consumed by processes. Such constraints help to prevent denial-of-service attacks by a script that attempts to flood a system's resources.
With Solaris resource management features, you can designate resources for particular projects. You can also dynamically adjust the resources that are available. For more information, see Part I, Resource Management, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
Solaris zones provide an application execution environment in which processes are isolated from the rest of the system within a single instance of the Solaris OS. This isolation prevents processes that are running in one zone from monitoring or affecting processes that are running in other zones. Even a process running with superuser capabilities cannot view or affect activity in other zones.
Solaris zones are ideal for environments that place several applications on a single server. For more information, see Part II, Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.
As a system administrator, you need to monitor system activity. You need to be aware of all aspects of your machines, including the following:
What is the normal load?
Who has access to the system?
When do individuals access the system?
What programs normally run on the system?
With this kind of knowledge, you can use the available tools to audit system use and monitor the activities of individual users. Monitoring is very useful when a breach in security is suspected. For more information on the auditing service, see Chapter 28, Solaris Auditing (Overview).
As a system administrator, you need assurance that the files that were installed on the systems that you administer have not changed in unexpected ways. In large installations, a comparison and reporting tool about the software stack on each of your systems enables you to track your systems. The Basic Audit Reporting Tool (BART) enables you to comprehensively validate systems by performing file-level checks of one or more systems over time. Changes in a BART manifest across systems, or for one system over time, can validate the integrity of your systems. BART provides manifest creation, manifest comparison, and rules for scripting reports. For more information, see Chapter 5, Using the Basic Audit Reporting Tool (Tasks).
The Solaris OS is a multiuser environment. In a multiuser environment, all the users who are logged in to a system can read files that belong to other users. With the appropriate file permissions, users can also use files that belong to other users. For more discussion, see Chapter 6, Controlling Access to Files (Tasks). For step-by-step instructions on setting appropriate permissions on files, see Protecting Files (Task Map).
You can keep a file secure by making the file inaccessible to other users. For example, a file with permissions of 600 cannot be read except by its owner and by superuser. A directory with permissions of 700 is similarly inaccessible. However, someone who guesses your password or who discovers the root password can access that file. Also, the otherwise inaccessible file is preserved on a backup tape every time that the system files are backed up to offline media.
The Solaris Cryptographic Framework provides digest, mac, and encrypt commands to protect files. For more information, see Chapter 13, Solaris Cryptographic Framework (Overview).
ACLs, pronounced “ackkls,” can provide greater control over file permissions. You add ACLs when traditional UNIX file protections are not sufficient. Traditional UNIX file protections provide read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides finer-grained file security.
ACLs enable you to define the following file permissions:
Owner file permissions
File permissions for the owner's group
File permissions for other users who are outside the owner's group
File permissions for specific users
File permissions for specific groups
Default permissions for each of the previous categories
For more information about using ACLs, see Using Access Control Lists to Protect UFS Files.
A network file server can control which files are available for sharing. A network file server can also control which clients have access to the files, and what type of access is permitted for those clients. In general, the file server can grant read-write access or read-only access either to all clients or to specific clients. Access control is specified when resources are made available with the share command.
The /etc/dfs/dfstab file on the file server lists the file systems that the server makes available to clients on the network. For more information about sharing file systems, see Automatic File System Sharing in System Administration Guide: Network Services.
In general, superuser is not allowed root access to file systems that are shared across the network. The NFS system prevents root access to mounted file systems by changing the user of the requester to the user nobody with the user ID 60001. The access rights of user nobody are the same as those access rights that are given to the public. The user nobody has the access rights of a user without credentials. For example, if the public has only execute permission for a file, then user nobody can only execute that file.
An NFS server can grant superuser capabilities on a shared file system on a per-host basis. To grant these privileges, use the root=hostname option to the share command. You should use this option with care. For a discussion of security options with NFS, see Chapter 6, Accessing Network File Systems (Reference), in System Administration Guide: Network Services.
Computers are often part of a configuration of computers. This configuration is called a network. A network allows connected computers to exchange information. Networked computers can access data and other resources from other computers on the network. Computer networks create a powerful and sophisticated computing environment. However, networks also complicate computer security.
For example, within a network of computers, individual machines allow the sharing of information. Unauthorized access is a security risk. Because many people have access to a network, unauthorized access is more likely, especially through user error. A poor use of passwords can also allow unauthorized access.
Network security is usually based on limiting or blocking operations from remote systems. The following figure describes the security restrictions that you can impose on remote operations.
Authentication is a way to restrict access to specific users when these users access a remote system. Authentication can be set up at both the system level and the network level. After a user has gained access to a remote system, authorization is a way to restrict operations that the user can perform. The following table lists the services that provide authentication and authorization.
Table 2–3 Authentication and Authorization Services for Remote Access
Service |
Description |
For More Information |
---|---|---|
IPsec |
IPsec provides host-based and certificate-based authentication and network traffic encryption. |
Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services |
Kerberos |
Kerberos uses encryption to authenticate and authorize a user who is logging in to the system. |
For an example, see How the Kerberos Service Works. |
LDAP and NIS+ |
The LDAP directory service and the NIS+ name service can provide both authentication and authorization at the network level. |
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (NIS+) |
Remote login commands |
The remote login commands enable users to log in to a remote system over the network and use its resources. Some of the remote login commands are rlogin, rcp, and ftp. If you are a “trusted host,” authentication is automatic. Otherwise, you are asked to authenticate yourself. |
Chapter 29, Accessing Remote Systems (Tasks), in System Administration Guide: Network Services |
SASL |
The Simple Authentication and Security Layer (SASL) is a framework that provides authentication and optional security services to network protocols. Plugins enable you to choose an appropriate authentication protocol. | |
Secure RPC |
Secure RPC improves the security of network environments by authenticating users who make requests on remote machines. You can use either the UNIX, DES, or Kerberos authentication system for Secure RPC. | |
|
Secure RPC can also be used to provide additional security in an NFS environment. An NFS environment with secure RPC is called Secure NFS. Secure NFS uses Diffie-Hellman authentication for public keys. | |
Solaris Secure Shell |
Solaris Secure Shell encrypts network traffic over an unsecured network. Solaris Secure Shell provides authentication by the use of passwords, public keys, or both. Solaris Secure Shell uses RSA and DSA authentication for public keys. |
A possible substitute for Secure RPC is the Solaris privileged port mechanism. A privileged port is assigned a port number less than 1024. After a client system has authenticated the client's credential, the client builds a connection to the server by using the privileged port. The server then verifies the client credential by examining the connection's port number.
Clients that are not running Solaris software might be unable to communicate by using the privileged port. If the clients cannot communicate over the port, you see an error message that is similar to the following:
“Weak Authentication NFS request from unprivileged port” |
You can set up a firewall system to protect the resources in your network from outside access. A firewall system is a secure host that acts as a barrier between your internal network and outside networks. The internal network treats every other network as untrusted. You should consider this setup as mandatory between your internal network and any external networks, such as the Internet, with which you communicate.
A firewall acts as a gateway and as a barrier. A firewall acts as a gateway that passes data between the networks. A firewall acts as a barrier that blocks the free passage of data to and from the network. The firewall requires a user on the internal network to log in to the firewall system to access hosts on remote networks. Similarly, a user on an outside network must first log in to the firewall system before being granted access to a host on the internal network.
A firewall can also be useful between some internal networks. For example, you can set up a firewall or a secure gateway computer to restrict the transfer of packets. The gateway can forbid packet exchange between two networks, unless the gateway computer is the source address or the destination address of the packet. A firewall should also be set up to forward packets for particular protocols only. For example, you can allow packets for transferring mail, but not allow packets for the telnet or the rlogin command. ASET, when run at high security, disables the forwarding of Internet Protocol (IP) packets.
In addition, all electronic mail that is sent from the internal network is first sent to the firewall system. The firewall then transfers the mail to a host on an external network. The firewall system also receives all incoming electronic mail, and distributes the mail to the hosts on the internal network.
A firewall prevents unauthorized users from accessing the hosts on your network. You should maintain strict and rigidly enforced security on the firewall, but security on other hosts on the network can be more relaxed. However, an intruder who can break into your firewall system can then gain access to all the other hosts on the internal network.
A firewall system should not have any trusted hosts. A trusted host is a host from which a user can log in without being required to supply a password. A firewall system should not share any of its file systems, or mount any file systems from other servers.
The following technologies can be used to harden a system into a firewall:
ASET enforces high security on a firewall system, as described in Chapter 7, Using the Automated Security Enhancement Tool (Tasks).
The Sun Security Toolkit, informally known as the JASS toolkit, can harden a Solaris system into a firewall. The toolkit can be downloaded from the Sun web site, http://www.sun.com/software/security/jass.
IPsec and Solaris IP filter can provide firewall protection. For more information on protecting network traffic, see Part IV, IP Security, in System Administration Guide: IP Services.
Most local area networks transmit data between computers in blocks that are called packets. Through a procedure that is called packet smashing, unauthorized users from outside the network can corrupt or destroy data.
Packet smashing involves capturing the packets before the packets reach their destination. The intruder then injects arbitrary data into the contents, and sends the packets back on their original course. On a local area network, packet smashing is impossible because packets reach all systems, including the server, at the same time. Packet smashing is possible on a gateway, however, so make sure that all gateways on the network are protected.
The most dangerous attacks affect the integrity of the data. Such attacks involve changing the contents of the packets or impersonating a user. Attacks that involve eavesdropping do not compromise data integrity. An eavesdropper records conversations for later replay. An eavesdropper does not impersonate a user. Although eavesdropping attacks do not attack data integrity, the attacks do affect privacy. You can protect the privacy of sensitive information by encrypting data that goes over the network.
To encrypt remote operations over an insecure network, see Chapter 19, Using Solaris Secure Shell (Tasks).
To encrypt and authenticate data across a network, see Chapter 21, Introduction to the Kerberos Service.
To encrypt IP datagrams, see Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services.
If you experience a suspected security breach, you can contact the Computer Emergency Response Team/Coordination Center (CERT/CC). CERT/CC is a Defense Advanced Research Projects Agency (DARPA) funded project that is located at the Software Engineering Institute at Carnegie Mellon University. This agency can assist you with any security problems you are having. This agency can also direct you to other Computer Emergency Response Teams that might be more appropriate for your particular needs. You can call CERT/CC at its 24-hour hotline: (412) 268-7090. Or, contact the team by email at cert@cert.sei.cmu.edu.
This chapter describes the procedures for controlling who can access Solaris systems. The following is a list of the information in this chapter.
For overview information about system security, see Chapter 2, Managing Machine Security (Overview).
A computer is as secure as its weakest point of entry. The following task map shows the areas that you should monitor and secure.
Task |
Description |
For Instructions |
---|---|---|
Monitor, permit, and deny user login |
Monitors unusual login activity. Prevents logins temporarily. Manages dial-up logins. | |
Provide strong password encryption |
Specifies algorithms to encrypt user passwords. Installs additional algorithms. | |
Monitor and restrict superuser activities |
Regularly monitors superuser activity. Prevents remote login by a root user. | |
Prevent access to hardware settings |
Keeps ordinary users away from the PROM. |
The following task map points to procedures that monitor user logins and that disable user logins.
Task |
Description |
For Instructions |
---|---|---|
Display a user's login status |
Lists extensive information about a user's login account, such as full name and password aging information. | |
Find users who do not have passwords |
Finds only those users whose accounts do not require a password. | |
Disable logins temporarily |
Denies user logins to a machine as part of system shutdown or routine maintenance. | |
Save failed login attempts |
Creates a log of users who failed to provide the correct password after five attempts. | |
Save all failed login attempts |
Creates a log of failed attempts to log in. | |
Create a dial-up password |
Requires an additional password for users who log in remotely through a modem or dial-up port. | |
Disable dial-up logins temporarily |
Prevents users from dialing in remotely through a modem or port. |
You can limit remote logins and require users to have passwords. You can also monitor failed access attempts and disable logins temporarily.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Display a user's login status by using the logins command.
# logins -x -l username |
Displays an extended set of login status information.
Displays the login status for the specified user. The variable username is a user's login name. Multiple login names must be specified in a comma-separated list.
The logins command uses the appropriate password database to obtain a user's login status. The database can be the local /etc/passwd file, or a password database for the name service. For more information, see the logins(1M) man page.
In the following example, the login status for the user rimmer is displayed.
# logins -x -l rimmer rimmer 500 staff 10 Annalee J. Rimmer /export/home/rimmer /bin/sh PS 010103 10 7 -1 |
Identifies the user's login name.
Identifies the user ID (UID).
Identifies the user's primary group.
Identifies the group ID (GID).
Identifies the comment.
Identifies the user's home directory.
Identifies the login shell.
Specifies the password aging information:
Last date that the password was changed
Number of days that are required between changes
Number of days before a change is required
Warning period
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Display all users who have no passwords by using the logins command.
# logins -p |
The -p option displays a list of users with no passwords. The logins command uses the password database from the local system unless a name service is enabled.
In the following example, the user pmorph does not have a password.
# logins -p pmorph 501 other 1 Polly Morph # |
Temporarily disable user logins during system shutdown or routine maintenance. Superuser logins are not affected. For more information, see the nologin(4) man page.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create the /etc/nologin file in a text editor.
# vi /etc/nologin |
Include a message about system availability.
Close and save the file.
In this example, users are notified of system unavailability.
# vi /etc/nologin (Add system message here) # cat /etc/nologin ***No logins permitted.*** ***The system will be unavailable until 12 noon.*** |
You can also bring the system to run level 0, single-user mode, to disable logins. For information on bringing the system to single-user mode, see Chapter 10, Shutting Down a System (Tasks), in System Administration Guide: Basic Administration.
This procedure captures failed login attempts from terminal windows. This procedure does not capture failed logins from a CDE or GNOME login attempt.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create the loginlog file in the /var/adm directory.
# touch /var/adm/loginlog |
Set read-and-write permissions for root user on the loginlog file.
# chmod 600 /var/adm/loginlog |
Change group membership to sys on the loginlog file.
# chgrp sys /var/adm/loginlog |
Verify that the log works.
For example, log in to the system five times with the wrong password. Then, display the /var/adm/loginlog file.
# more /var/adm/loginlog jdoe:/dev/pts/2:Tue Nov 4 10:21:10 2003 jdoe:/dev/pts/2:Tue Nov 4 10:21:21 2003 jdoe:/dev/pts/2:Tue Nov 4 10:21:30 2003 jdoe:/dev/pts/2:Tue Nov 4 10:21:40 2003 jdoe:/dev/pts/2:Tue Nov 4 10:21:49 2003 # |
The loginlog file contains one entry for each failed attempt. Each entry contains the user's login name, tty device, and time of the failed attempt. If a person makes fewer than five unsuccessful attempts, no failed attempts are logged.
A growing loginlog file can indicate an attempt to break into the computer system. Therefore, check and clear the contents of this file regularly. For more information, see the loginlog(4) man page.
This procedure captures in a syslog file all failed login attempts.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Set up the /etc/default/login file with the desired values for SYSLOG and SYSLOG_FAILED_LOGINS
Edit the /etc/default/login file to change the entry. Make sure that SYSLOG=YES is uncommented.
# grep SYSLOG /etc/default/login # SYSLOG determines whether the syslog(3) LOG_AUTH facility # should be used SYSLOG=YES … SYSLOG_FAILED_LOGINS=0 # |
Create a file with the correct permissions to hold the logging information.
Edit the syslog.conf file to log failed password attempts.
The failures should be sent to the authlog file.
Verify that the log works.
For example, as an ordinary user, log in to the system with the wrong password. Then, in the Primary Administrator role or as superuser, display the /var/adm/authlog file.
# more /var/adm/authlog Nov 4 14:46:11 example1 login: [ID 143248 auth.notice] Login failure on /dev/pts/8 from example2, stacey # |
Monitor the /var/adm/authlog file on a regular basis.
Follow the preceding procedure, except set the value of SYSLOG_FAILED_LOGINS to 3 in the /etc/default/login file.
Uncomment the RETRIES entry in the /etc/default/login file, then set the value of RETRIES to 3. Your edits take effect immediately. After three login retries in one session, the system closes the connection.
When you first establish a dial-up password, be sure to remain logged in to at least one port. Test the password on a different port. If you log off to test the new password, you might not be able to log back in. If you are still logged in to another port, you can go back and fix your mistake.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create an /etc/dialups file that contains a list of serial devices.
Include all the ports that are being protected with dial-up passwords. The /etc/dialups file should appear similar to the following:
/dev/term/a /dev/term/b /dev/term/c |
Create an /etc/d_passwd file that contains the login programs that you are requiring to have a dial-up password.
Include shell programs that a user could be running at login, for example, uucico, sh, ksh, and csh. The /etc/d_passwd file should appear similar to the following:
/usr/lib/uucp/uucico:encrypted-password: /usr/bin/csh:encrypted-password: /usr/bin/ksh:encrypted-password: /usr/bin/sh:encrypted-password: |
Later in the procedure, you are going to add the encrypted password for each login program.
Set ownership to root on the two files.
# chown root /etc/dialups /etc/d_passwd |
Set group ownership to root on the two files.
# chgrp root /etc/dialups /etc/d_passwd |
Set read-and-write permissions for root on the two files.
# chmod 600 /etc/dialups /etc/d_passwd |
Create the encrypted passwords.
Create a temporary user.
# useradd username |
Create a password for the temporary user.
# passwd username New Password: <Type password> Re-enter new Password: <Retype password> passwd: password successfully changed for username |
Capture the encrypted password.
# grep username /etc/shadow > username.temp |
Edit the username.temp file.
Delete all fields except the encrypted password. The second field holds the encrypted password.
For example, in the following line, the encrypted password is U9gp9SyA/JlSk.
temp:U9gp9SyA/JlSk:7967:::::7988: |
Delete the temporary user.
# userdel username |
Copy the encrypted password from username.temp file into the /etc/d_passwd file.
You can create a different password for each login shell. Alternatively, use the same password for each login shell.
Inform your dial-up users of the password.
You should ensure that your means of informing the users cannot be tampered with.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Put the following single-line entry into the /etc/d_passwd file:
/usr/bin/sh:*: |
The following task map points to procedures to administer password algorithms.
Task |
For Instructions |
---|---|
Provide strong password encryption | |
Provide strong password encryption with a name service | |
Add new password encryption module |
How to Install a Password Encryption Module From a Third Party |
By default, user passwords are encrypted with the crypt_unix algorithm. You can use a stronger encryption algorithm, such as MD5 or Blowfish, by changing the default password encryption algorithm.
In this procedure, the BSD-Linux version of the MD5 algorithm is the default encryption algorithm that is used when users change their passwords. This algorithm is suitable for a mixed network of machines that run the Solaris, BSD, and Linux versions of UNIX. For a list of password encryption algorithms and algorithm identifiers, see Table 2–1.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Specify the identifier for your chosen encryption algorithm.
Type the identifier as the value for the CRYPT_DEFAULT variable in the /etc/security/policy.conf file.
You might want to comment the file to explain your choice.
# cat /etc/security/policy.conf … CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6 # # Use the version of MD5 that works with Linux and BSD systems. # Passwords previously encrypted with __unix__ will be encrypted with MD5 # when users change their passwords. # # CRYPT_DEFAULT=__unix__ CRYPT_DEFAULT=1 |
In this example, the algorithms configuration ensures that the weakest algorithm, crypt_unix, is never used to encrypt a password. Users whose passwords were encrypted with the crypt_unix module get a crypt_bsdmd5-encrypted password when they change their passwords.
For more information on configuring the algorithm choices, see the policy.conf(4) man page.
In this example, the identifier for the Blowfish algorithm, 2a, is specified as the value for the CRYPT_DEFAULT variable in the policy.conf file:
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6 #CRYPT_ALGORITHMS_DEPRECATE=__unix__ CRYPT_DEFAULT=2a |
This configuration is compatible with BSD systems that use the Blowfish algorithm.
When users in an NIS domain change their passwords, the NIS client consults its local algorithms configuration in the /etc/security/policy.conf file. The NIS client machine encrypts the password.
Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS client.
Copy the modified /etc/security/policy.conf file to every client machine in the NIS domain.
To minimize confusion, copy the modified /etc/security/policy.conf file to the NIS root server and to the slave servers.
When users in an NIS+ domain change their passwords, the NIS+ name service consults the algorithms configuration in the /etc/security/policy.conf file on the NIS+ master. The NIS+ master, which is running the rpc.nispasswd daemon, creates the encrypted password.
Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS+ master.
To minimize confusion, copy the NIS+ master's /etc/security/policy.conf file to every host in the NIS+ domain.
When the LDAP client is properly configured, the LDAP client can use the new password algorithms. The LDAP client behaves just as an NIS client behaves.
Specify a password encryption algorithm in the /etc/security/policy.conf file on the LDAP client.
Copy the modified policy.conf file to every client machine in the LDAP domain.
Ensure that the client's /etc/pam.conf file does not use a pam_ldap module.
Ensure that a comment sign (#) precedes entries that include pam_ldap.so.1. Also, do not use the new server_policy option with the pam_authtok_store.so.1 module.
The PAM entries in the client's pam.conf file enable the password to be encrypted according to the local algorithms configuration. The PAM entries also enable the password to be authenticated.
When users in the LDAP domain change their passwords, the LDAP client consults its local algorithms configuration in the /etc/security/policy.conf file. The LDAP client machine encrypts the password. Then, the client sends the encrypted password, with a {crypt} tag, to the server. The tag tells the server that the password is already encrypted. The password is then stored, as is, on the server. For authentication, the client retrieves the stored password from the server. The client then compares the stored password with the encrypted version that the client has just generated from the user's typed password.
To take advantage of password policy controls on the LDAP server, use the server_policy option with the pam_authtok_store entries in the pam.conf file. Passwords are then encrypted on the server by using the Sun Java System Directory Server's cryptographic mechanism. For the procedure, see Chapter 11, Setting Up Sun Java System Directory Server With LDAP Clients (Tasks), in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
A third-party password encryption algorithm is typically delivered as a module in a software package. When you run the pkgadd command, scripts from the vendor should modify the /etc/security/crypt.conf file. You then modify the /etc/security/policy.conf file to include the new module and its identifier.
Add the software by using the pkgadd command.
For detailed instructions on how to add software, see Adding or Removing a Software Package (pkgadd) in System Administration Guide: Basic Administration.
Confirm that the new module and module identifier have been added.
Read the list of encryption algorithms in the /etc/security/crypt.conf file.
For example, the following lines show that a module that implements the crypt_rot13 algorithm has been installed.
# crypt.conf # md5 /usr/lib/security/$ISA/crypt_md5.so rot13 /usr/lib/security/$ISA/crypt_rot13.so # For *BSD - Linux compatibility # 1 is MD5, 2a is Blowfish 1 /usr/lib/security/$ISA/crypt_bsdmd5.so 2a /usr/lib/security/$ISA/crypt_bsdbf.so |
Add the identifier of the newly installed algorithm to the /etc/security/policy.conf file.
The following lines show excerpts from the policy.conf file that would need to be modified to add the rot13 identifier.
# Copyright 1999-2002 Sun Microsystems, Inc. All rights reserved. # ... #ident "@(#)policy.conf 1.12 08/05/14 SMI" # ... # crypt(3c) Algorithms Configuration CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6,,rot13 #CRYPT_ALGORITHMS_DEPRECATE=__unix__ CRYPT_DEFAULT=md5 |
In this example, the rot13 algorithm is used if the current password was encrypted with the crypt_rot13 algorithm. New user passwords are encrypted with the crypt_sunmd5 algorithm. This algorithm configuration works on Solaris-only networks.
The following task map describes how to monitor and restrict the root user login.
Task |
Description |
For Instructions |
---|---|---|
Monitor who is using the su command |
Scans the sulog file on a regular basis. | |
Display superuser activity on the console |
Monitors superuser access attempts as the attempts occur. |
An alternative to using the superuser account is to set up role-based access control. Role-based access control is called RBAC. For overview information on RBAC, see Role-Based Access Control (Overview). To set up RBAC, see Chapter 9, Using Role-Based Access Control (Tasks).
The sulog file lists every use of the su command, not only the su attempts that are used to switch from user to superuser.
Monitor the contents of the /var/adm/sulog file on a regular basis.
# more /var/adm/sulog SU 12/20 16:26 + pts/0 stacey-root SU 12/21 10:59 + pts/0 stacey-root SU 01/12 11:11 + pts/0 root-rimmer SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root |
The entries display the following information:
The date and time that the command was entered.
If the attempt was successful. A plus sign (+) indicates a successful attempt. A minus sign (-) indicates an unsuccessful attempt.
The port from which the command was issued.
The name of the user and the name of the switched identity.
The su logging in this file is enabled by default through the following entry in the /etc/default/su file:
SULOG=/var/adm/sulog |
Entries that include ??? indicate that the controlling terminal for the su command cannot be identified. Typically, system invocations of the su command before the desktop appears include ???, as in SU 10/10 08:08 + ??? root-root. After the user starts a desktop session, the ttynam command returns the value of the controlling terminal to the sulog: SU 10/10 10:10 + pts/3 jdoe-root.
Entries similar to the following can indicate that the su command was not invoked on the command line: SU 10/10 10:20 + ??? root-oracle. The user might have switched to the oracle role by using a GUI.
This method immediately detects superuser attempts to access the local system.
View the CONSOLE entry in the /etc/default/login file.
CONSOLE=/dev/console |
By default, the console device is set to /dev/console. With this setting, root can log in to the console. root cannot log in remotely.
Verify that root cannot log in remotely.
From a remote system, try to log in as superuser.
mach2 % rlogin -l root mach1 Password: <Type root password of mach1> Not on system console Connection closed. |
Monitor attempts to become superuser.
By default, attempts to become superuser are printed to the console by the SYSLOG utility.
In this example, superuser attempts are not being logged by SYSLOG. Therefore, the administrator is logging those attempts by removing the comment from the #CONSOLE=/dev/console entry in the /etc/default/su file.
# CONSOLE determines whether attempts to su to root should be logged # to the named device # CONSOLE=/dev/console |
When a user attempts to become superuser, the attempt is printed on the terminal console.
SU 09/07 16:38 + pts/8 jdoe-root |
To become superuser from a remote system when the /etc/default/login file contains the default CONSOLE entry, users must first log in with their user name. After logging in with their user name, users then can use the su command to become superuser.
If the console displays an entry similar to Mar 16 16:20:36 mach1 login: ROOT LOGIN /dev/pts/14 FROM mach2.Example.COM, then the system is permitting remote root logins. To prevent remote superuser access, change the #CONSOLE=/dev/console entry to CONSOLE=/dev/console in the /etc/default/login file.
The following task map describes how to protect the PROM from unwanted access.
Task |
Description |
For Instructions |
---|---|---|
Prevent users from changing system hardware settings |
Requires a password to modify PROM settings. | |
Disable the abort sequence |
Prevents users from accessing the PROM. |
You can protect the physical machine by requiring a password to gain access to the hardware settings. You can also protect the machine by preventing a user from using the abort sequence to leave the windowing system.
On an x86 system, the equivalent to protecting the PROM is to protect the BIOS. Refer to your machine's manuals for how to protect the BIOS.
Become superuser or assume a role that includes the Device Security profile, the Maintenance and Repair profile, or the System Administrator profile.
The System Administrator profile includes the Maintenance and Repair profile. To create a role that includes the System Administrator profile and to assign the role to a user, see Configuring RBAC (Task Map).
In a terminal window, type the PROM security mode.
# eeprom security-mode=command Changing PROM password: New password: <Type password> Retype new password: <Retype password> |
Choose the value command or full. For more details, see the eeprom(1M) man page.
If, when you type the preceding command, you are not prompted for a PROM password, the system already has a PROM password.
(Optional) To change the PROM password, type the following command:
# eeprom security-password= Press Return Changing PROM password: New password: <Type password> Retype new password: <Retype password> |
The new PROM security mode and password are in effect immediately. However, they are most likely to be noticed at the next boot.
Do not forget the PROM password. The hardware is unusable without this password.
Some server systems have a key switch. When the key switch is set in the secure position, the switch overrides the software keyboard abort settings. So, any changes that you make with the following procedure might not be implemented.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Change the value of KEYBOARD_ABORT to disable.
Comment out the enable line in the /etc/default/kbd file. Then, add a disable line:
# cat /etc/default/kbd … # KEYBOARD_ABORT affects the default behavior of the keyboard abort # sequence, see kbd(1) for details. The default value is "enable". # The optional value is "disable". Any other value is ignored. … #KEYBOARD_ABORT=enable KEYBOARD_ABORT=disable |
Update the keyboard defaults.
# kbd -i |
This chapter provides step-by-step instructions for protecting devices, in addition to a reference section. The following is a list of the information in this chapter.
For overview information about device protection, see Controlling Access to Devices.
The following task map points to tasks for managing access to devices.
Task |
For Instructions |
---|---|
Manage device policy | |
Manage device allocation | |
Use device allocation |
The following task map points to device configuration procedures that are related to device policy.
Task |
Description |
For Instructions |
---|---|---|
View the device policy for the devices on your system |
Lists the devices and their device policy. | |
Require privilege for device use |
Uses privileges to protect a device. | |
Remove privilege requirements from a device |
Removes or lessens the privileges that are required to access a device. | |
Audit changes in device policy |
Records changes in device policy in the audit trail | |
Access /dev/arp |
Gets Solaris IP MIB-II information. |
Device policy restricts or prevents access to devices that are integral to the system. The policy is enforced in the kernel.
Display the device policy for all devices on your system.
% getdevpolicy | more DEFAULT read_priv_set=none write_priv_set=none ip:* read_priv_set=net_rawaccess write_priv_set=net_rawaccess … |
In this example, the device policy for three devices is displayed.
% getdevpolicy /dev/allkmem /dev/ipsecesp /dev/hme /dev/allkmem read_priv_set=all write_priv_set=all /dev/ipsecesp read_priv_set=sys_net_config write_priv_set=sys_net_config /dev/hme read_priv_set=net_rawaccess write_priv_set=net_rawaccess |
Assume a role that includes the Device Security rights profile, or become superuser.
The Primary Administrator role includes the Device Security rights profile. You can also assign the Device Security rights profile to a role that you create. To create the role and assign the role to a user, see Example 9–3.
Add policy to a device.
# update_drv -a -p policy device-driver |
Specifies a policy for device-driver.
Is the device policy for device-driver. Device policy specifies two sets of privileges. One set is required to read the device. The other set is required to write to the device.
Is the device driver.
For more information, see the update_drv(1M) man page.
In the following example, device policy is added to the ipnat device.
# getdevpolicy /dev/ipnat /dev/ipnat read_priv_set=none write_priv_set=none # update_drv -a \ -p 'read_priv_set=net_rawaccess write_priv_set=net_rawaccess' ipnat # getdevpolicy /dev/ipnat /dev/ipnat read_priv_set=net_rawaccess write_priv_set=net_rawaccess |
In the following example, the read set of privileges is removed from the device policy for the ipnat device.
# getdevpolicy /dev/ipnat /dev/ipnat read_priv_set=net_rawaccess write_priv_set=net_rawaccess # update_drv -a -p write_priv_set=net_rawaccess ipnat # getdevpolicy /dev/ipnat /dev/ipnat read_priv_set=none write_priv_set=net_rawaccess |
By default, the as audit class includes the AUE_MODDEVPLCY audit event.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Preselect the audit class that includes AUE_MODDEVPLCY audit event.
Add the as class to the flags line of the audit_control file. The file would appear similar to the following:
# audit_control file dir:/var/audit flags:lo,as minfree:20 naflags:lo |
For detailed instructions, see How to Modify the audit_control File.
Applications that retrieve Solaris IP MIB-II information should open /dev/arp, not /dev/ip.
Determine the device policy on /dev/ip and /dev/arp.
% getdevpolicy /dev/ip /dev/arp /dev/ip read_priv_set=net_rawaccess write_priv_set=net_rawaccess /dev/arp read_priv_set=none write_priv_set=none |
Note that the net_rawaccess privilege is required for reading and writing to /dev/ip. No privileges are required for /dev/arp.
Open /dev/arp and push the tcp and udp modules.
No privileges are required. This method is equivalent to opening /dev/ip and pushing the arp, tcp and udp modules. Because opening /dev/ip now requires a privilege, the /dev/arp method is preferred.
The following task map points to procedures that enable and configure device allocation. Device allocation is not enabled by default. After device allocation is enabled, see Allocating Devices (Task Map).
Task |
Description |
For Instructions |
---|---|---|
Make a device allocatable |
Enables a device to be allocated to one user at a time. | |
Authorize users to allocate a device |
Assigns device allocation authorizations to users. | |
View the allocatable devices on your system |
Lists the devices that are allocatable, and the state of the device. | |
Forcibly allocate a device |
Allocates a device to a user who has an immediate need | |
Forcibly deallocate a device |
Deallocates a device that is currently allocated to a user | |
Change the allocation properties of a device |
Changes the requirements for allocating a device | |
Create a device-clean script |
Purges data from a physical device. | |
Disable device allocation |
Removes allocation restrictions from all devices. | |
Audit device allocation |
Records device allocation in the audit trail |
Device allocation restricts or prevents access to peripheral devices. Restrictions are enforced at user allocation time. By default, users must have authorization to access allocatable devices.
If you have already run the bsmconv command to enable auditing, then device allocation is already enabled on your system. For more information, see the bsmconv(1M) man page.
Assume a role that includes the Audit Control rights profile, or become superuser.
The Primary Administrator role includes the Audit Control rights profile. You can also assign the Audit Control rights profile to a role that you create. To create the role and assign the role to a user, see Example 9–3.
# bsmconv This script is used to enable the Basic Security Module (BSM). Shall we continue with the conversion now? [y/n] y bsmconv: INFO: checking startup file. bsmconv: INFO: move aside /etc/rc3.d/S81volmgt. bsmconv: INFO: turning on audit module. bsmconv: INFO: initializing device allocation files. The Basic Security Module is ready. If there were any errors, please fix them now. Configure BSM by editing files located in /etc/security. Reboot this system now to come up with BSM enabled. |
The Volume Management daemon (/etc/rc3.d/S81volmgt) is disabled by this command.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Create a rights profile that contains the appropriate authorization and commands.
Typically, you would create a rights profile that includes the solaris.device.allocate authorization. Follow the instructions in How to Create or Change a Rights Profile. Give the rights profile appropriate properties, such as the following:
Rights profile name: Device Allocation
Granted authorizations: solaris.device.allocate
Commands with security attributes: mount with the sys_mount privilege, and umount with the sys_mount privilege
Create a role for the rights profile.
Follow the instructions in How to Create and Assign a Role by Using the GUI. Use the following role properties as a guide:
Role name: devicealloc
Role full name: Device Allocator
Role description: Allocates and mounts allocated devices
Rights profile: Device Allocation
This rights profile must be at the top of the list of profiles that are included in the role.
Assign the role to every user who is permitted to allocate a device.
Teach the users how to use device allocation.
For examples of allocating removable media, see How to Allocate a Device.
Because the Volume Management daemon (vold) is not running, removable media are not automatically mounted. For examples of mounting a device that has been allocated, see How to Mount an Allocated Device.
Device allocation must be enabled for this procedure to succeed. To enable device allocation, see How to Make a Device Allocatable.
Assume a role that includes the Device Security rights profile, or become superuser.
The Primary Administrator role includes the Device Security rights profile. You can also assign the Device Security rights profile to a role that you create. To create the role and assign the role to a user, see Example 9–3.
Display information about allocatable devices on your system.
# list_devices device-name |
where device-name is one of the following:
audio[n] – Is a microphone and speaker.
fd[n] – Is a diskette drive.
sr[n] – Is a CD-ROM drive.
st[n] – Is a tape drive.
If the list_devices command returns an error message similar to the following, then either device allocation is not enabled, or you do not have sufficient permissions to retrieve the information.
list_devices: No device maps file entry for specified device.
For the command to succeed, enable device allocation and assume a role with the solaris.device.revoke authorization.
Forcible allocation is used when someone has forgotten to deallocate a device. Forcible allocation can also be used when a user has an immediate need for a device.
The user or role must have the solaris.device.revoke authorization.
Determine if you have the appropriate authorizations in your role.
$ auths solaris.device.allocate solaris.device.revoke |
Forcibly allocate the device to the user who needs the device.
In this example, the tape drive is forcibly allocated to the user jdoe.
$ allocate -U jdoe |
Devices that a user has allocated are not automatically deallocated when the process terminates or when the user logs out. Forcible deallocation is used when a user has forgotten to deallocate a device.
The user or role must have the solaris.device.revoke authorization.
Determine if you have the appropriate authorizations in your role.
$ auths solaris.device.allocate solaris.device.revoke |
Forcibly deallocate the device.
In this example, the printer is forcibly deallocated. The printer is now available for allocation by another user.
$ deallocate -f /dev/lp/printer-1 |
Assume a role that includes the Device Security rights profile, or become superuser.
The Primary Administrator role includes the Device Security rights profile. You can also assign the Device Security rights profile to a role that you create. To create the role and assign the role to a user, see Example 9–3.
Specify if authorization is required, or specify the solaris.device.allocate authorization.
Change the fifth field in the device entry in the device_allocate file.
audio;audio;reserved;reserved;solaris.device.allocate;/etc/security/lib/audio_clean fd0;fd;reserved;reserved;solaris.device.allocate;/etc/security/lib/fd_clean sr0;sr;reserved;reserved;solaris.device.allocate;/etc/security/lib/sr_clean |
where solaris.device.allocate indicates that a user must have the solaris.device.allocate authorization to use the device.
In the following example, any user on the system can allocate any device. The fifth field in every device entry in the device_allocate file has been changed to an at sign (@).
$ whoami devicesec $ vi /etc/security/device_allocate audio;audio;reserved;reserved;@;/etc/security/lib/audio_clean fd0;fd;reserved;reserved;@;/etc/security/lib/fd_clean sr0;sr;reserved;reserved;@;/etc/security/lib/sr_clean … |
In the following example, the audio device cannot be used. The fifth field in the audio device entry in the device_allocate file has been changed to an asterisk (*).
$ whoami devicesec $ vi /etc/security/device_allocate audio;audio;reserved;reserved;*;/etc/security/lib/audio_clean fd0;fd;reserved;reserved;solaris device.allocate;/etc/security/lib/fd_clean sr0;sr;reserved;reserved;solaris device.allocate;/etc/security/lib/sr_clean … |
In the following example, no peripheral device can be used. The fifth field in every device entry in the device_allocate file has been changed to an asterisk (*).
$ whoami devicesec $ vi /etc/security/device_allocate audio;audio;reserved;reserved;*;/etc/security/lib/audio_clean fd0;fd;reserved;reserved;*;/etc/security/lib/fd_clean sr0;sr;reserved;reserved;*;/etc/security/lib/sr_clean … |
By default, the device allocation commands are in the other audit class.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Preselect the ot class for auditing.
Add the ot class to the flags line of the audit_control file. The file would appear similar to the following:
# audit_control file dir:/var/audit flags:lo,ot minfree:20 naflags:lo |
For detailed instructions, see How to Modify the audit_control File.
The following task map points to procedures that show users how to allocate devices.
Task |
Description |
For Instructions |
---|---|---|
Allocate a device |
Enables a user to use a device, while preventing any other user from using the device. | |
Mount an allocated device |
Enables a user to view a device that requires mounting, such as a CD-ROM or a diskette. | |
Deallocate a device |
Makes an allocatable device available for use by another user. |
Device allocation reserves the use of a device to one user at a time. Devices that require a mount point must be mounted.
Device allocation must be enabled, as described in How to Make a Device Allocatable. If authorization is required, the user must have the authorization.
Allocate the device.
Specify the device by device name.
% allocate device-name |
Verify that the device is allocated.
Run the identical command.
% allocate device-name allocate. Device already allocated. |
In this example, the user jdoe allocates a microphone, audio.
% whoami jdoe % allocate audio |
In this example, a user allocates a printer. No one else can print to printer-1 until the user deallocates it, or until the printer is forcibly allocated to another user.
% allocate /dev/lp/printer-1 |
For an example of forcible deallocation, see Forcibly Deallocating a Device.
In this example, the user jdoe allocates a tape drive, st0.
% whoami jdoe % allocate st0 |
If the allocate command cannot allocate the device, an error message is displayed in the console window. For a list of allocation error messages, see the allocate(1) man page.
The user or role has allocated the device. To mount a device, the user or role must have the privileges that are required for mounting the device. To give the required privileges, see How to Authorize Users to Allocate a Device.
Assume a role that can allocate and mount a device.
% su - role-name Password: <Type role-name password> $ |
Create and protect a mount point in the role's home directory.
You only need to do this step the first time you need a mount point.
$ mkdir mount-point ; chmod 700 mount-point |
List the allocatable devices.
$ list_devices -l List of allocatable devices |
Allocate the device.
Specify the device by device name.
$ allocate device-name |
Mount the device.
$ mount -o ro -F filesystem-type device-path mount-point |
where
Indicates that the device is to be mounted read-only. Use-o rw to indicate that you should be able to write to the device.
Indicates the file system format of the device. Typically, a CD-ROM is formatted with an HSFS file system. A diskette is typically formatted with a PCFS file system.
Indicates the path to the device. The output of the list_devices -l command includes the device-path.
Indicates the mount point that you created in Step 2.
In this example, a user assumes a role that can allocate and mount a diskette drive, fd0. The diskette is formatted with a PCFS file system.
% roles devicealloc % su - devicealloc Password: <Type devicealloc password> $ mkdir /home/devicealloc/mymnt $ chmod 700 /home/devicealloc/mymnt $ list_devices -l ... device: fd0 type: fd files: /dev/diskette /dev/rdiskette /dev/fd0a ... $ allocate fd0 $ mount -o ro -F pcfs /dev/diskette /home/devicealloc/mymnt $ ls /home/devicealloc/mymnt List of the contents of diskette |
In this example, a user assumes a role that can allocate and mount a CD-ROM drive, sr0. The drive is formatted as an HSFS file system.
% roles devicealloc % su - devicealloc Password: <Type devicealloc password> $ mkdir /home/devicealloc/mymnt $ chmod 700 /home/devicealloc/mymnt $ list_devices -l ... device: sr0 type: sr files: /dev/sr0 /dev/rsr0 /dev/dsk/c0t2d0s0 ... ... $ allocate sr0 $ mount -o ro -F hsfs /dev/sr0 /home/devicealloc/mymnt $ cd /home/devicealloc/mymnt ; ls List of the contents of CD-ROM |
If the mount command cannot mount the device, an error message is displayed: mount: insufficient privileges. Check the following:
Make sure that you are executing the mount command in a profile shell. If you have assumed a role, the role has a profile shell. If you are a user who has been assigned a profile with the mount command, you must create a profile shell. The commands pfsh, pfksh, and pfcsh create a profile shell.
Make sure that you own the specified mount point. You should have read, write, and execute access to the mount point.
Contact your administrator if you still cannot mount the allocated device.
Deallocation enables other users to allocate and use the device when you are finished.
You must have allocated the device.
If the device is mounted, unmount the device.
$ cd $HOME $ umount mount-point |
Deallocate the device.
$ deallocate device-name |
In this example, the user jdoe deallocates the microphone, audio.
% whoami jdoe % deallocate audio |
In this example, the Device Allocator role deallocates a CD-ROM drive. After the message is printed, the CD-ROM is ejected.
$ whoami devicealloc $ cd /home/devicealloc $ umount /home/devicealloc/mymnt $ ls /home/devicealloc/mymnt $ $ deallocate sr0 /dev/sr0: 326o /dev/rsr0: 326o … sr_clean: Media in sr0 is ready. Please, label and store safely. |
Devices in the Solaris OS are protected by device policy. Peripheral devices can be protected by device allocation. Device policy is enforced by the kernel. Device allocation is optionally enabled, and is enforced at the user level.
Device management commands administer the device policy on local files. Device policy can include privilege requirements. Only superuser or a role of equivalent capabilities can manage devices.
The following table lists the device management commands.
Table 4–1 Device Management Commands
Command |
Purpose |
Man Page |
---|---|---|
Administers devices and device drivers on a running system. Also loads device policy. The devfsadm command enables the cleanup of dangling /dev links to disk, tape, port, audio, and pseudo devices. Devices for a named driver can also be reconfigured. | ||
Displays the policy associated with one or more devices. This command can be run by any user. | ||
Adds a new device driver to a running system. Contains options to add device policy to the new device. Typically, this command is called in a script when a device driver is being installed. | ||
Updates the attributes of an existing device driver. Contains options to update the device policy for the device. Typically, this command is called in a script when a device driver is being installed. | ||
Removes a device or device driver. |
Device allocation can protect your site from loss of data, computer viruses, and other security breaches. Unlike device policy, device allocation is optional. Devices are not allocatable until the bsmconv script is run. Device allocation uses authorizations to limit access to allocatable devices.
The components of the device allocation mechanism are as follows:
The allocate, deallocate, dminfo, and list_devices commands. For more information, see Device Allocation Commands.
Device-clean scripts for each allocatable device.
These commands and scripts use the following local files to implement device allocation:
The /etc/security/device_allocate file. For more information, see the device_allocate(4) man page.
The /etc/security/device_maps file. For more information, see the device_maps(4) man page.
A lock file, in the /etc/security/dev directory, for each allocatable device.
The changed attributes of the lock files that are associated with each allocatable device.
The /etc/security/dev directory might not be supported in future releases of the Solaris OS.
With uppercase options, the allocate, deallocate, and list_devices commands are administrative commands. Otherwise, these commands are user commands. The following table lists the device allocation commands.
Table 4–2 Device Allocation Commands
By default, users must have the solaris.device.allocate authorization to reserve an allocatable device. To create a rights profile to include the solaris.device.allocate authorization, see How to Authorize Users to Allocate a Device.
Administrators must have the solaris.device.revoke authorization to change the allocation state of any device. For example, the -U option to the allocate and list_devices commands, and the -F option to the deallocate command require the solaris.device.revoke authorization.
For more information, see Commands That Require Authorizations.
A device is put in an allocate error state when the deallocate command fails to deallocate, or when the allocate command fails to allocate. When an allocatable device is in an allocate error state, then the device must be forcibly deallocated. Only superuser or a role with the Device Management rights profile or the Device Security rights profile can handle an allocate error state.
The deallocate command with the -F option forces deallocation. Or, you can use allocate -U to assign the device to a user. Once the device is allocated, you can investigate any error messages that appear. After any problems with the device are corrected, you can forcibly deallocate it.
Device maps are created when you set up device allocation. A default /etc/security/device_maps file is created by the bsmconv command when the auditing service is enabled. This initial device_maps file can be customized for your site. The device_maps file includes the device names, device types, and device-special files that are associated with each allocatable device.
The device_maps file defines the device-special file mappings for each device, which in many cases is not intuitive. This file allows programs to discover which device-special files map to which devices. You can use the dminfo command, for example, to retrieve the device name, the device type, and the device-special files to specify when you set up an allocatable device. The dminfo command uses the device_maps file to report this information.
Each device is represented by a one-line entry of the form:
device-name:device-type:device-list |
The following is an example of an entry in a device_maps file for a diskette drive, fd0:
fd0:\ fd:\ /dev/diskette /dev/rdiskette /dev/fd0a /dev/rfd0a \ /dev/fd0b /dev/rfd0b /dev/fd0c /dev/fd0 /dev/rfd0c /dev/rfd0:\ |
Lines in the device_maps file can end with a backslash (\) to continue an entry on the next line. Comments can also be included. A pound sign (#) comments all subsequent text until the next newline that is not immediately preceded by a backslash. Leading and trailing blanks are allowed in any field. The fields are defined as follows:
Specifies the name of the device. For a list of current device names, see How to View Allocation Information About a Device.
Specifies the generic device type. The generic name is the name for the class of devices, such as st, fd, or audio. The device-type field logically groups related devices.
Lists the device-special files that are associated with the physical device. The device-list must contain all of the special files that allow access to a particular device. If the list is incomplete, a malevolent user can still obtain or modify private information. Valid entries for the device-list field reflect the device files that are located in the /dev directory.
An initial /etc/security/device_allocate file is created by the bsmconv command when the auditing service is enabled. This initial device_allocate file can be used as a starting point. You can modify the device_allocate file to change devices from allocatable to nonallocatable, or to add new devices. A sample device_allocate file follows.
st0;st;;;;/etc/security/lib/st_clean fd0;fd;;;;/etc/security/lib/fd_clean sr0;sr;;;;/etc/security/lib/sr_clean audio;audio;;;*;/etc/security/lib/audio_clean |
An entry in the device_allocate file does not mean that the device is allocatable, unless the entry specifically states that the device is allocatable. In the sample device_allocate file, note the asterisk (*) in the fifth field of the audio device entry. An asterisk in the fifth field indicates to the system that the device is not allocatable. Therefore, the device cannot be used. Other values or no value in this field indicates that the device can be used.
In the device_allocate file, each device is represented by a one-line entry of the form:
device-name;device-type;reserved;reserved;auths;device-exec |
Lines in the device_allocate file can end with a backslash (\) to continue an entry on the next line. Comments can also be included. A pound sign (#) comments all subsequent text until the next newline that is not immediately preceded by a backslash. Leading and trailing blanks are allowed in any field. The fields are defined as follows:
Specifies the name of the device. For a list of current device names, see How to View Allocation Information About a Device.
Specifies the generic device type. The generic name is the name for the class of devices, such as st, fd, and sr. The device-type field logically groups related devices. When you make a device allocatable, retrieve the device name from the device-type field in the device_maps file.
Sun reserves the two fields that are marked reserved for future use.
Specifies whether the device is allocatable. An asterisk (*) in this field indicates that the device is not allocatable. An authorization string, or an empty field, indicates that the device is allocatable. For example, the string solaris.device.allocate in the auths field indicates that the solaris.device.allocate authorization is required to allocate the device. An at sign (@) in this file indicates that the device is allocatable by any user.
Supplies the path name of a script to be invoked for special handling, such as cleanup and object-reuse protection during the allocation process. The device-exec script is run any time that the device is acted on by the deallocate command.
For example, the following entry for the sr0 device indicates that the CD-ROM drive is allocatable by a user with the solaris.device.allocate authorization:
sr0;sr;reserved;reserved;solaris.device.allocate;/etc/security/lib/sr_clean |
You can decide to accept the default devices and their defined characteristics. After you install a new device, you can modify the entries. Any device that needs to be allocated before use must be defined in the device_allocate and device_maps files for that device's system. Currently, cartridge tape drives, diskette drives, CD-ROM drives, and audio chips are considered allocatable. These device types have device-clean scripts.
Xylogics tape drives or Archive tape drives also use the st_clean script that is supplied for SCSI devices. You need to create your own device-clean scripts for other devices, such as modems, terminals, graphics tablets, and other allocatable devices. The script must fulfill object-reuse requirements for that type of device.
Device allocation satisfies part of what is called the object reuse requirement. The device-clean scripts address the security requirement that all usable data be purged from a physical device before reuse. The data is cleared before the device is allocatable by another user. By default, cartridge tape drives, diskette drives, CD-ROM drives, and audio devices require device-clean scripts. The Solaris OS provides the scripts. This section describes what device-clean scripts do.
The st_clean device-clean script supports three tape devices:
SCSI ¼-inch tape
Archive ¼-inch tape
Open-reel ½-inch tape
The st_clean script uses the rewoffl option to the mt command to clean up the device. For more information, see the mt(1) man page. If the script runs during system boot, the script queries the device to determine if the device is online. If the device is online, the script determines if the device has media in it. The ¼-inch tape devices that have media in them are placed in the allocate error state. The allocate error state forces the administrator to manually clean up the device.
During normal system operation, when the deallocate command is executed in interactive mode, the user is prompted to remove the media. Deallocation is delayed until the media is removed from the device.
The following device-clean scripts are provided for diskettes and CD-ROM drives:
The scripts use the eject command to remove the media from the drive. If the eject command fails, the device is placed in the allocate error state. For more information, see the eject(1) man page.
Audio devices are cleaned up with an audio_clean script. The script performs an AUDIO_GETINFO ioctl system call to read the device. The script then performs an AUDIO_SETINFO ioctl system call to reset the device configuration to the default.
If you add more allocatable devices to the system, you might need to create your own device-clean scripts. The deallocate command passes a parameter to the device-clean scripts. The parameter, which is shown here, is a string that contains the device name. For more information, see the device_allocate(4) man page.
clean-script -[I|i|f|S] device-name |
Device-clean scripts must return “0” for success and greater than “0” for failure. The options -I, -f, and -S determine the running mode of the script:
Is needed during system boot only. All output must go to the system console. Failure or inability to forcibly eject the media must put the device in the allocate error state.
Is for forced cleanup. The option is interactive and assumes that the user is available to respond to prompts. A script with this option must attempt to complete the cleanup if one part of the cleanup fails.
Is for standard cleanup. The option is interactive and assumes that the user is available to respond to prompts.
This chapter describes how to create a manifest of the files on a system and how to use that manifest to check the integrity of the system. The Basic Audit Reporting Tool (BART) enables you to comprehensively validate systems by performing file-level checks of a system over time.
The following is a list of the information in this chapter:
BART is a file tracking tool that operates entirely at the file system level. Using BART gives you the ability to quickly, easily, and reliably gather information about the components of the software stack that is installed on deployed systems. Using BART can greatly reduce the costs of administering a network of systems by simplifying time-consuming administrative tasks.
BART enables you to determine what file-level changes have occurred on a system, relative to a known baseline. You use BART to create a baseline or control manifest from a fully installed and configured system. You can then compare this baseline with a snapshot of the system at a later time, generating a report that lists file-level changes that have occurred on the system since it was installed.
The bart command is a standard UNIX command. You can redirect the output of the bart command to a file for later processing.
BART has been designed with an emphasis on a simple syntax that is both powerful and flexible. The tool enables you to generate manifests of a given system over time. Then, when the system's files need to be validated, you can generate a report by comparing the old and new manifests. Another way to use BART is to generate manifests of several similar systems and run system-to-system comparisons. The main difference between BART and existing auditing tools is that BART is flexible, both in terms of what information is tracked and what information is reported.
Additional benefits and uses of BART include the following:
Provides an efficient and easy method for cataloging a system that is running the Solaris software at the file level.
Enables you to define which files to monitor and gives you the ability to modify profiles when necessary. This flexibility allows you to monitor local customizations and enables you to reconfigure software easily and efficiently.
Ensures that systems are running reliable software.
Allows you to monitor file-level changes of a system over time, which can help you locate corrupted or unusual files.
Helps you troubleshoot system performance issues.
BART has two main components and one optional component:
BART Manifest
BART Report
BART Rules File
You use the bart create command to take a file-level snapshot of a system at a particular time. The output is a catalog of files and file attributes called a manifest. The manifest lists information about all the files or specific files on a system. It contains information about attributes of files, which can include some uniquely identifying information, such as an MD5 checksum. For more information about the MD5 checksum, see the md5(3EXT) man page. A manifest can be stored and transferred between client and server systems.
BART does not cross file system boundaries, with the exception of file systems of the same type. This constraint makes the output of the bart create command more predictable. For example, without arguments, the bart create command catalogs all file systems under the root (/) directory. However, no NFS or TMPFS file systems or mounted CD-ROMs would be cataloged. When creating a manifest, do not attempt to audit file systems on a network. Note that using BART to monitor networked file systems can consume large resources to generate manifests that will have little value.
For more information about BART manifests, see BART Manifest File Format.
The report tool has three inputs: the two manifests to be compared and an optional user-provided rules file that indicates which discrepancies are to be flagged.
You use the bart compare command to compare two manifests, a control manifest and a test manifest. These manifests must be prepared with the same file systems, options, and rules file that you use with the bart create command.
The output of the bart compare command is a report that lists per-file discrepancies between the two manifests. A discrepancy is a change to any attribute for a given file that is cataloged for both manifests. Additions or deletions of file entries between the two manifests are also considered discrepancies.
There are two levels of control when reporting discrepancies:
When generating a manifest
When producing reports
These levels of control are intentional, since generating a manifest is more costly than reporting discrepancies between two manifests. Once you have created manifests, you have the ability to compare manifests from different perspectives by running the bart compare command with different rules files.
For more information about BART reports, see BART Reporting.
The rules file is a text file that you can optionally use as input to the bart command. This file uses inclusion and exclusion rules. A rules file is used to create custom manifests and reports. A rules file enables you to express in a concise syntax which sets of files you want to catalog, as well as which attributes to monitor for any given set of files. When you compare manifests, the rules file aids in flagging discrepancies between the manifests. Using a rules file is an effective way to gather specific information about files on a system.
You create a rules file by using a text editor. With a rules file, you can perform the following tasks:
Use the bart create command to create a manifest that lists information about all or specific files on a system.
Use the bart compare command to generate a report that monitors specific attributes of a file system.
You can create several rules files for different purposes. However, if you create a manifest by using a rules file, you must use the same rules file when you compare the manifests. If you do not use the same rules file when comparing manifests that were created with a rules file, the output of the bart compare command will list many invalid discrepancies.
A rules file can also contain syntax errors and other ambiguous information as a result of user error. If a rules file does contain misinformation, these errors will also be reported.
Using a rules file to monitor specific files and file attributes on a system requires planning. Before you create a rules file, decide which files and file attributes on the system you want to monitor. Depending on what you are trying to accomplish, you might use a rules file to create manifests, compare manifests, or for purposes.
For more information about the BART rules file, see BART Rules File Format and the bart_rules(4) man page.
Task |
Description |
For Instructions |
---|---|---|
Create a manifest. |
Obtain a manifest that lists information about every file that is installed on a system. | |
Create a custom manifest. |
Obtain a manifest that lists information about specific files that are installed on a system in one of the following ways:
|
|
Compare manifests for the same system over time. Or, compare manifests for different systems with a control system manifest. |
Obtain a report that compares changes to a system over time. Or, obtain a report that compares one or several systems to control system. |
How to Compare Manifests for the Same System Over Time How to Compare Manifests From a Different System With the Manifest of a Control System |
(Optional) Customize a BART report. |
Obtain a custom BART report in one of the following ways:
|
How to Customize a BART Report by Specifying File Attributes |
You can run the bart command as a regular user, superuser, or a user who has assumed the Primary Administrator role. If you run the bart command as a regular user, you will only be able to catalog and monitor files that you have permission to access, for example, information about files in your home directory. The advantage of becoming superuser when you run the bart command is that the manifests you create will contain information about hidden and private files that you might want to monitor. If you need to catalog and monitor information about files that have restricted permissions, for example, the /etc/passwd or /etc/shadow file, run the bart command as superuser or assume an equivalent role. For more information about using role-based access control, see Configuring RBAC (Task Map).
Running the bart command as superuser makes the output readable by anyone. This output might contain file names that are intended to be private. If you become superuser when you run the bart command, take appropriate measures to protect the output. For example, use options that generate output files with restrictive permissions.
The procedures and examples in this chapter show the bart command run by superuser. Unless otherwise specified, running the bart command as superuser is optional.
You can create a manifest of a system immediately after an initial Solaris software installation. This type of manifest will provide you with a baseline for comparing changes to the same system over time. Or, you can use this manifest to compare with the manifests for different systems. For example, if you take a snapshot of each system on your network, and then compare each test manifest with the control manifest, you can quickly determine what you need to do to synchronize the test system with the baseline configuration.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
After installing the Solaris software, create a control manifest and redirect the output to a file.
# bart create options > control-manifest |
Specifies the root directory for the manifest. All paths specified by the rules will be interpreted relative to this directory. All paths reported in the manifest will be relative to this directory.
Accepts a list of individual files to be cataloged, either on the command line or read from standard input.
Is the name of the rules file for this manifest. Note that –, when used with the -r option, will be read the rules file from standard input.
Turns off content signatures for all regular files in the file list. This option can be used to improve performance. Or, you can use this option if the contents of the file list are expected to change, as in the case of system log files.
Examine the contents of the manifest.
Save the manifest for future use.
Choose a meaningful name for the manifest. For example, use the system name and date that the manifest was created.
If you run the bart create command without any options, information about every file that is installed on the system will be cataloged. Use this type of manifest as a baseline when you are installing many systems from a central image. Or, use this type of manifest to run comparisons when you want to ensure that the installations are identical.
For example:
# bart create ! Version 1.0 ! Thursday, December 04, 2003 (16:17:39) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 1024 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9ea47 0 0 /.java D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f8dc04d 0 10 /.java/.userPrefs D 512 40700 user::rwx,group::---,mask:--- other:--- 3f8dc06b 010 /.java/.userPrefs/.user.lock.root F 0 100600 user::rw- group::---,mask:---,other:--- 3f8dc06b 0 10 - /.java/.userPrefs/.userRootModFile.root F 0 100600 user::rw-, group::---,mask:---,other:--- 3f8dc0a1 0 10 - . . . /var/sadm/pkg/SUNWdtmad/install/depend F 932 100644 user::rw-, group::r--,mask:r--,other:r-- 3c23a19e 0 0 - /var/sadm/pkg/SUNWdtmad/pkginfo F 594 100644 user::rw- group::r--,mask:r--,other:r-- 3f81e416 0 0 - /var/sadm/pkg/SUNWdtmad/save D 512 40755 user::rwx,group::r-x mask:r-x,other:r-x 3f81e416 0 0 /var/sadm/pkg/SUNWdtmaz D 512 40755 user::rwx,group::r-x mask:r-x,other:r-x 3f81e41b 0 0 /var/sadm/pkg/TSIpgxw/save D 512 40755 user::rwx group::r-x,mask:r-x,other:r-x 3f81e892 0 0 . . . |
Each manifest consists of a header and entries. Each manifest file entry is a single line, depending on the file type. For example, for each manifest entry in the preceding output, type F specifies a file and type D specifies a directory. Also listed is information about size, content, user ID, group ID, and permissions. File entries in the output are sorted by the encoded versions of the file names to correctly handle special characters. All entries are sorted in ascending order by file name. All nonstandard file names, such as those that contain embedded newline or tab characters, have the nonstandard characters quoted before being sorted.
Lines that begin with ! supply metadata about the manifest. The manifest version line indicates the manifest specification version. The date line shows the date on which the manifest was created, in date form. See the date(1) man page. Some lines are ignored by the manifest comparison tool. Ignored lines include blank lines, lines that consist only of white space, and comments that begin with #.
You can customize a manifest in one of the following ways:
By specifying a subtree
Creating a manifest for an individual subtree on a system is an efficient way to monitor changes to specific files, rather than the entire contents of a large directory. You can create a baseline manifest of a specific subtree on your system, then periodically create test manifests of the same subtree. Use the bart compare command to compare the control manifest with the test manifest. By using this option, you are able to efficiently monitor important file systems to determine whether any files have been compromised by an intruder.
By specifying a file name
Since creating a manifest that catalogs the entire system is more time-consuming, takes up more space, and is more costly, you might choose to use this option of the bart command when you want to only list information about a specific file or files on a system.
By using a rules file
You use a rules file to create custom manifests that list information about specific files and specific subtrees on a given system. You can also use a rules file to monitor specific file attributes. Using a rules file to create and compare manifests gives you the flexibility to specify multiple attributes for more than one file or subtree. Whereas, from the command line, you can only specify a global attribute definition that applies to all files for each manifest you create or report you generate.
Determine which files you want to catalog and monitor.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
After installing the Solaris software, create a custom manifest by using one of the following options:
By specifying a subtree:
# bart create -R root-directory |
By specifying a file name or file names:
# bart create -I filename... |
For example:
# bart create -I /etc/system /etc/passwd /etc/shadow |
By using a rules file:
# bart create -r rules-file |
Examine the contents of the manifest.
Save the manifest for future use.
This example shows how to create a manifest that contains information about the files in the /etc/ssh subtree only.
# bart create -R /etc/ssh ! Version 1.0 ! Saturday, November 29, 2003 (14:05:36) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f81eab9 0 3 /ssh_config F 861 100644 user::rw-,group::r--,mask:r--, other:r-- 3f81e504 0 3 422453ca0e2348cd9981820935600395 /ssh_host_dsa_key F 668 100600 user::rw-,group::---,mask:---, other:--- 3f81eab9 0 0 5cc28cdc97e833069fd41ef89e4d9834 /ssh_host_dsa_key.pub F 602 100644 user::rw-,group::r--,mask:r--, other:r-- 3f81eab9 0 0 16118c736995a4e4754f5ab4f28cf917 /ssh_host_rsa_key F 883 100600 user::rw-,group::---,mask:---, other:--- 3f81eaa2 0 0 6ff17aa968ecb20321c448c89a8840a9 /ssh_host_rsa_key.pub F 222 100644 user::rw-,group::r--,mask:r--, other:r-- 3f81eaa2 0 0 9ea27617efc76058cb97aa2caa6dd65a . . . |
This example shows how to create a manifest that lists only information about the /etc/passwd and /etc/shadow files on a system.
# bart create -I /etc/passwd /etc/shadow ! Version 1.0 ! Monday, December 15, 2003 (16:28:55) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode /etc/passwd F 542 100444 user::r--,group::r--,mask:r--, other:r-- 3fcfd45b 0 3 d6 84554f85d1de06219d80543174ad1a /etc/shadow F 294 100400 user::r--,group::---,mask:---, other:--- 3f8dc5a0 0 3 fd c3931c1ae5ee40341f3567b7cf15e2 |
By comparison, the following is the standard output of the ls -al command for the /etc/passwd and the /etc/shadow files on the same system.
# ls -al /etc/passwd -r--r--r-- 1 root sys 542 Dec 4 17:42 /etc/passwd |
# ls -al /etc/shadow -r-------- 1 root sys 294 Oct 15 16:09 /etc/shadow |
This example shows how to create a manifest by using a rules file to catalog only those files in the /etc directory. The same rules file includes directives to be used by the bart compare command for monitoring changes to the acl attribute of the /etc/system file.
Use a text editor to create a rules file that catalogs only those files in the /etc directory.
# List information about all the files in the /etc directory. CHECK all /etc # Check only acl changes in the /etc/system file IGNORE all CHECK acl /etc/system |
For more information about creating a rules file, see BART Rules File.
Create a control manifest by using the rules file you created.
# bart create -r etc.rules-file > etc.system.control-manifest ! Version 1.0 ! Thursday, December 11, 2003 (21:51:32) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode /etc/system F 1883 100644 user::rw-,group::r--,mask:r--, other:r-- 3f81db61 0 3 |
Create a test manifest whenever you want to monitor changes to the system. Prepare the test manifest identically to the control manifest by using the same bart options and the same rules file.
Compare manifests by using the same rules file.
Use this procedure when you want to monitor file-level changes to the same system over time. This type of manifest can assist you in locating corrupted or unusual files, detecting security breaches, or in troubleshooting performance issues on a system.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
After installing the Solaris software, create a control manifest of the files that you want to monitor on the system.
# bart create -R /etc > control-manifest |
Create a test manifest that is prepared identically to the control manifest whenever you want monitor changes to the system.
# bart create -R /etc > test-manifest |
Compare the control manifest with the test manifest.
# bart compare options control-manifest test-manifest > bart-report |
Is the name of the rules file for this comparison. Using the -r option with the – means that the directives will be read from standard input.
Allows the user to set global IGNORE directives from the command line.
Is the programmatic mode that generates standard non-localized output for programmatic parsing.
Is the output from the bart create command for the control system.
Is the output from the bart create command of the test system.
Examine the BART report for oddities.
This example shows how to monitor changes that have occurred in the /etc directory between two points in time. This type of comparison enables you to quickly determine whether important files on the system have been compromised.
Create a control manifest.
# bart create -R /etc > system1.control.121203 ! Version 1.0 ! Friday, December 12, 2003 (08:34:51) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 4096 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9dfb4 0 3 /.cpr_config F 2236 100644 user::rw-,group::r--,mask:r--,other:r-- 3fd9991f 0 0 67cfa2c830b4ce3e112f38c5e33c56a2 /.group.lock F 0 100600 user::rw-,group::---,mask:---,other:--- 3f81f14d 0 1 d41 d8cd98f00b204e9800998ecf8427e /.java D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f81dcb5 0 2 /.java/.systemPrefs D 512 40755 user::rwx,group::r-x,mask:r-x, other:r-x 3f81dcb7 . . . |
Create a test manifest when you want to monitor changes to the /etc directory.
# bart create -R /etc > system1.test.121503 Version 1.0 ! Monday, December 15, 2003 (08:35:28) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 4096 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9dfb4 0 3 /.cpr_config F 2236 100644 user::rw-,group::r--,mask:r--,other:r-- 3fd9991f 0 0 67cfa2c830b4ce3e112f38c5e33c56a2 /.group.lock F 0 100600 user::rw-,group::---,mask:---,other:--- 3f81f14d 0 1 d41d8cd98f00b204e9800998ecf8427e /.java D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f81dcb5 0 2 /.java/.systemPrefs D 512 40755 user::rwx,group::r-x,mask:r-x, other:r-x 3f81dcb70 2 /.java/.systemPrefs/.system.lock F 0 100644 user::rw-,group::r-- ,mask:r--,other: r-- 3f81dcb5 0 2 d41d8cd98f00b204e9800998ecf8427e /.java/.systemPrefs/.systemRootModFile F 0 100644 user::rw-, group::r--,mask:r--, other:r-- 3f81dd0b 0 2 d41d8cd98f00b204e9800998ecf8427e . . . |
Compare the control manifest with the test manifest.
# bart compare system1.control.121203 system1.test.121503 /vfstab: mode control:100644 test:100777 acl control:user::rw-,group::r--,mask:r--,other:r-- test:user::rwx, group::rwx,mask:rwx,other:rwx |
The preceding output indicates permissions on the vfstab file have changed since the control manifest was created. This report can be used to investigate whether ownership, date, content, or any other file attributes have changed. Having this type of information readily available can assist you in tracking down who might have tampered with the file and when the change might have occurred.
You can run system to system comparisons, thereby enabling you to quickly determine whether there are any file-level differences between a baseline system and the other systems. For example, if you have installed a particular version of the Solaris software on a baseline system, and you want to know whether other systems have identical packages installed, you can create manifests for those systems and then compare the test manifests with the control manifest. This type of comparison will list any discrepancies in the file contents for each test system that you compare with the control system.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
After installing the Solaris software, create a control manifest.
# bart create options > control-manifest |
Save the control manifest.
On the test system, use the same bart options to create a manifest, and redirect the output to a file.
# bart create options > test1-manifest |
Choose a distinct and meaningful name for the test manifest.
Save the test manifest to a central location on the system until you are ready to compare manifests.
When you want to compare manifests, copy the control manifest to the location of the test manifest. Or, copy the test manifest to the control system.
For example:
# cp control-manifest /net/test-server/bart/manifests
If the test system is not an NFS-mounted system, use FTP or some other reliable means to copy the control manifest to the test system.
Compare the control manifest with the test manifest and redirect the output to a file.
# bart compare control-manifest test1-manifest > test1.report |
Examine the BART report for oddities.
Repeat Step 4 through Step 9 for each test manifest that you want to compare with the control manifest.
Use the same bart options for each test system.
This example describes how to monitor changes to the contents of the /usr/bin directory by comparing a control manifest with a test manifest from a different system.
Create a control manifest.
# bart create -R /usr/bin > control-manifest.121203 !Version 1.0 ! Friday, December 12, 2003 (09:19:00) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 13312 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9e925 0 2 /.s F 14200 104711 user::rwx,group::--x,mask:--x,other:--x 3f8dbfd6 0 1 8ec7e52d8a35ba3b054a6394cbf71cf6 /ControlPanel L 28 120777 - 3f81dc71 0 1 jre/bin/ControlPanel /HtmlConverter L 25 120777 - 3f81dcdc 0 1 bin/HtmlConverter /acctcom F 28300 100555 user::r-x,group::r-x,mask:r-x,other:r-x 3f6b5750 0 2 d6e99b19c847ab4ec084d9088c7c7608 /activation-client F 9172 100755 user::rwx,group::r-x,mask:r-x, other:r-x 3f5cb907 0 1 b3836ad1a656324a6e1bd01edcba28f0 /adb F 9712 100555 user::r-x,group::r-x,mask:r-x,other:r-x 3f6b5736 0 2 5e026413175f65fb239ee628a8870eda /addbib F 11080 100555 user::r-x,group::r-x,mask:r-x,other:r-x 3f6b5803 0 2 a350836c36049febf185f78350f27510 . . . |
Create a test manifest for each system that you want to compare with the control system.
# bart create -R /usr/bin > system2-manifest.121503 ! Version 1.0 ! Friday, December 15, 2003 (13:30:58) # Format: #fname D size mode acl dirmtime uid gid #fname P size mode acl mtime uid gid #fname S size mode acl mtime uid gid #fname F size mode acl mtime uid gid contents #fname L size mode acl lnmtime uid gid dest #fname B size mode acl mtime uid gid devnode #fname C size mode acl mtime uid gid devnode / D 13312 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9ea9c 0 2 /.s F 14200 104711 user::rwx,group::--x,mask:--x,other:--x 3f8dbfd6 0 1 8ec7e52d8a35ba3b054a6394cbf71cf6 /ControlPanel L 28 120777 - 3f81dc71 0 1 jre/bin/ControlPanel /HtmlConverter L 25 120777 - 3f81dcdc 0 1 bin/HtmlConverter /acctcom F 28300 100555 user::r-x,group::r-x,mask:r-x,other: r-x 3f6b5750 0 2 d6e99b19c847ab4ec084d9088c7c7608 . . . |
When you want to compare manifests, copy the manifests to the same location.
# cp control-manifest /net/system2.central/bart/manifests |
Compare the control manifest with the test manifest.
# bart compare control-manifest system2.test > system2.report /su: gid control:3 test:1 /ypcat: mtime control:3fd72511 test:3fd9eb23 |
The previous output indicates that the group ID of the su file in the /usr/bin directory is not the same as that of the control system. This information can be helpful in determining whether a different version of the software was installed on the test system or if possibly someone has tampered with the file.
This procedure is optional and explains how to customize a BART report by specifying file attributes from the command line. If you create a baseline manifest that lists information about all the files or specific on your system, you can run the bart compare command, specifying different attributes, whenever you need to monitor changes to a particular directory, subdirectory, file or files. You can run different types of comparisons for the same manifests by specifying different file attributes from the command line.
Determine which file attributes you want to monitor.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
After installing the Solaris software, create a control manifest.
Create a test manifest when you want to monitor changes.
Prepare the test manifest identically to the control manifest.
Compare the manifests.
For example:
# bart compare -i dirmtime,lnmtime,mtime control-manifest.121503 \ test-manifest.010504 > bart.report.010504 |
Note that a comma separates each attribute you specify in the command-line syntax.
Examine the BART report for oddities.
This procedure is also optional and explains how to customize a BART report by using a rules file as input to the bart compare command. By using a rules file, you can customize a BART report, which allows you the flexibility of specifying multiple attributes for more than one file or subtree. You can run different comparisons for the same manifests by using different rules files.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Determine which files and file attributes you want to monitor.
Use a text editor to create a rules file with the appropriate directives.
After installing the Solaris software, create a control manifest by using the rules file you created.
# bart create -r rules-file > control-manifest |
Create a test manifest that is prepared identically to the control manifest.
# bart create -r rules-file > test-manifest |
Compare the control manifest with the test manifest by using the same rules file.
# bart compare -r rules-file control-manifest test-manifest > bart.report |
Examine the BART report for oddities.
The following rules file includes directives for both the bart create and the bart compare commands. The rules file directs the bart create command to list information about the contents of the /usr/bin directory. In addition, the rules file directs the bart compare command to track only size and content changes in the same directory.
# Check size and content changes in the /usr/bin directory. # This rules file only checks size and content changes. # See rules file example. IGNORE all CHECK size contents /usr/bin |
Create a control manifest by using the rules file you created.
# bart create -r bartrules.txt > usr_bin.control-manifest.121003 |
Create a test manifest whenever you want to monitor changes to the /usr/bin directory.
# bart create -r bartrules.txt > usr_bin.test-manifest.121103 |
Compare the manifests by using the same rules file.
# bart compare -r bartrules.txt usr_bin.control-manifest \ usr_bin.test-manifest |
Examine the output of the bart compare command.
/usr/bin/gunzip: add /usr/bin/ypcat: delete |
In the preceding output, the bart compare command reported a discrepancy in the /usr/bin directory. This output indicates that /usr/bin/ypcat file was deleted, and the /usr/bin/gunzip file was added.
This section includes the following reference information:
Each manifest file entry is a single line, depending on the file type. Each entry begins with fname, which is the name of the file. To prevent parsing problems that are caused by special characters embedded in file names, the file names are encoded. For more information, see BART Rules File Format.
Subsequent fields represent the following file attributes:
Type of file with the following possible values:
B for a block device node
C for a character device node
D for a directory
F for a file
L for a symbolic link
P for a pipe
S for a socket
File size in bytes.
Octal number that represents the permissions of the file.
ACL attributes for the file. For a file with ACL attributes, this contains the output from acltotext().
Numerical user ID of the owner of this entry.
Numerical group ID of the owner of this entry.
Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for directories.
Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for links.
Last modification time, in seconds, since 00:00:00 UTC January 1, 1970, for files.
Checksum value of the file. This attribute is only specified for regular files. If you turn off context checking, or if checksums cannot be computed, the value of this field is –.
Destination of a symbolic link.
Value of the device node. This attribute is for character device files and block device files only.
For more information about BART manifests, see the bart_manifest(4) man page.
The input files to the bart command are text files. These files consist of lines that specify which files are to be included in the manifest and which file attributes are to be included the report. The same input file can be used across both pieces of BART functionality. Lines that begin with #, blank lines, and lines that contain white space are ignored by the tool.
The input files have three types of directives:
Subtree directive, with optional pattern matching modifiers
CHECK directive
IGNORE directive
<Global CHECK/IGNORE Directives> <subtree1> [pattern1..] <IGNORE/CHECK Directives for subtree1> <subtree2> [pattern2..] <subtree3> [pattern3..] <subtree4> [pattern4..] <IGNORE/CHECK Directives for subtree2, subtree3, subtree4> |
All directives are read in order, with later directives possibly overriding earlier directives.
There is one subtree directive per line. The directive must begin with an absolute pathname, followed by zero or more pattern matching statements.
The bart command uses CHECK and IGNORE statements to define which attributes to track or ignore. Each attribute has an associated keyword.
The attribute keywords are as follows:
acl
all
contents
dest
devnode
dirmtime
gid
lnmtime
mode
mtime
size
type
uid
The all keyword refers to all file attributes.
The rules file specification language that BART uses is the standard UNIX quoting syntax for representing nonstandard file names. Embedded tab, space, newline, or special characters are encoded in their octal forms to enable the tool to read file names. This nonuniform quoting syntax prevents certain file names, such as those containing an embedded carriage return, from being processed correctly in a command pipeline. The rules specification language allows the expression of complex file name filtering criteria that would be difficult and inefficient to describe by using shell syntax alone.
For more information about the BART rules file or the quoting syntax used by BART, see the bart_rules(4) man page.
In default mode, the bart compare command, as shown in the following example, will check all the files installed on the system, with the exception of modified directory timestamps (dirmtime):
CHECK all IGNORE dirmtime |
If you supply a rules file, then the global directives of CHECK all and IGNORE dirmtime, in that order, are automatically prepended to the rules file.
The following exit values are returned:
Success
Nonfatal error when processing files, such as permission problems
Fatal error, such as an invalid command-line option
The reporting mechanism provides two types of output: verbose and programmatic:
Verbose output is the default output and is localized and presented on multiple lines. Verbose output is internationalized and is human-readable. When the bart compare command compares two system manifests, a list of file differences is generated.
For example:
filename attribute control:xxxx test:yyyy |
Name of the file that differs between the control manifest and the test manifest.
Name of the file attribute that differs between the manifests that are compared. xxxx is the attribute value from the control manifest, and yyyy is the attribute value from the test manifest. When discrepancies for multiple attributes occur in the same file, each difference is noted on a separate line.
Following is an example of the default output for the bart compare command. The attribute differences are for the /etc/passwd file. The output indicates that the size, mtime, and contents attributes have changed.
/etc/passwd: size control:74 test:81 mtime control:3c165879 test:3c165979 contents control:daca28ae0de97afd7a6b91fde8d57afa test:84b2b32c4165887355317207b48a6ec7 |
Programmatic output is generated if you use the -p option when you run the bart compare command. This output is generated in a form that is suitable for programmatic manipulation. Programmatic output can be easily parsed by other programs and is designed to be used as input for other tools.
For example:
filename attribute control-val test-val [attribute control-val test-val]* |
Same as the filename attribute in the default format
A description of the file attributes that differ between the control and test manifests for each file
For a list of attributes that are supported by the bart command, see Rules File Attributes.
For more information about BART, see the bart(1M) man page.
This chapter describes how to protect files in the Solaris Operating System (Solaris OS). The chapter also describes how to protect the system from files whose permissions could compromise the system.
To protect ZFS files with access control lists (ACLs), see Chapter 8, Using ACLs to Protect Oracle Solaris ZFS Files, in Oracle Solaris ZFS Administration Guide.
The following is a list of the information in this chapter.
Files can be secured through UNIX file permissions and through ACLs. Files with sticky bits, and files that are executable, require special security measures.
This table describes the commands for monitoring and securing files and directories.
Table 6–1 Commands for Securing Files and Directories
Command |
Description |
Man Page |
---|---|---|
Lists the files in a directory and information about the files. | ||
Changes the ownership of a file. | ||
Changes the group ownership of a file. | ||
Changes permissions on a file. You can use either symbolic mode, which uses letters and symbols, or absolute mode, which uses octal numbers, to change permissions on a file. |
Traditional UNIX file permissions can assign ownership to three classes of users:
user – The file or directory owner, which is usually the user who created the file. The owner of a file can decide who has the right to read the file, to write to the file (make changes to it), or, if the file is a command, to execute the file.
group – Members of a group of users.
others – All other users who are not the file owner and are not members of the group.
The owner of the file can usually assign or modify file permissions. Additionally, users or roles with administrative capabilities, such as superuser or the Primary Administrator role, can change a file's ownership. To override system policy, see Example 6–2.
A file can be one of seven types. Each type is displayed by a symbol:
Block special file
Character special file
Directory
Symbolic link
Socket
Door
Named pipe (FIFO)
The following table lists and describes the permissions that you can give to each class of user for a file or directory.
Table 6–2 File and Directory Permissions
Symbol |
Permission |
Object |
Description |
---|---|---|---|
r |
Read |
File |
Designated users can open and read the contents of a file. |
|
|
Directory |
Designated users can list files in the directory. |
w |
Write |
File |
Designated users can modify the contents of the file or delete the file. |
|
|
Directory |
Designated users can add files or add links in the directory. They can also remove files or remove links in the directory. |
x |
Execute |
File |
Designated users can execute the file, if it is a program or shell script. They also can run the program with one of the exec(2) system calls. |
|
|
Directory |
Designated users can open files or execute files in the directory. They also can make the directory and the directories beneath it current. |
- |
Denied |
File and Directory |
Designated users cannot read, write, or execute the file. |
These file permissions apply to regular files, and to special files such as devices, sockets, and named pipes (FIFOs).
For a symbolic link, the permissions that apply are the permissions of the file that the link points to.
You can protect the files in a directory and its subdirectories by setting restrictive file permissions on that directory. Note, however, that superuser has access to all files and directories on the system.
Three special types of permissions are available for executable files and public directories: setuid, setgid, and sticky bit. When these permissions are set, any user who runs that executable file assumes the ID of the owner (or group) of the executable file.
You must be extremely careful when you set special permissions, because special permissions constitute a security risk. For example, a user can gain superuser capabilities by executing a program that sets the user ID (UID) to 0, which is the UID of root. Also, all users can set special permissions for files that they own, which constitutes another security concern.
You should monitor your system for any unauthorized use of the setuid permission and the setgid permission to gain superuser capabilities. A suspicious permission grants ownership of an administrative program to a user rather than to root or bin. To search for and list all files that use this special permission, see How to Find Files With Special File Permissions.
When setuid permission is set on an executable file, a process that runs this file is granted access on the basis of the owner of the file. The access is not based on the user who is running the executable file. This special permission allows a user to access files and directories that are normally available only to the owner.
For example, the setuid permission on the passwd command makes it possible for users to change passwords. A passwd command with setuid permission would resemble the following:
-r-sr-sr-x 3 root sys 28144 Jun 17 12:02 /usr/bin/passwd |
This special permission presents a security risk. Some determined users can find a way to maintain the permissions that are granted to them by the setuid process even after the process has finished executing.
The use of setuid permissions with the reserved UIDs (0–100) from a program might not set the effective UID correctly. Use a shell script, or avoid using the reserved UIDs with setuid permissions.
The setgid permission is similar to the setuid permission. The process's effective group ID (GID) is changed to the group that owns the file, and a user is granted access based on the permissions that are granted to that group. The /usr/bin/mail command has setgid permissions:
-r-x--s--x 1 root mail 67504 Jun 17 12:01 /usr/bin/mail |
When the setgid permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs. The files do not belong to the group to which the creating process belongs. Any user who has write and execute permissions in the directory can create a file there. However, the file belongs to the group that owns the directory, not to the group that the user belongs to.
You should monitor your system for any unauthorized use of the setgid permission to gain superuser capabilities. A suspicious permission grants group access to such a program to an unusual group rather than to root or bin. To search for and list all files that use this permission, see How to Find Files With Special File Permissions.
The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the file owner, the directory owner, or by a privileged user. The root user and the Primary Administrator role are examples of privileged users. The sticky bit prevents a user from deleting other users' files from public directories such as /tmp:
drwxrwxrwt 7 root sys 400 Sep 3 13:37 tmp |
Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system. For instructions, see Example 6–5.
When you create a file or directory, you create it with a default set of permissions. The system defaults are open. A text file has 666 permissions, which grants read and write permission to everyone. A directory and an executable file have 777 permissions, which grants read, write, and execute permission to everyone. Typically, users override the system defaults in their /etc/profile file, .cshrc file, or .login file.
The value assigned by the umask command is subtracted from the default. This process has the effect of denying permissions in the same way that the chmod command grants them. For example, the chmod 022 command grants write permission to group and others. The umask 022 command denies write permission to group and others.
The following table shows some typical umask settings and their effect on an executable file.
Table 6–3 umask Settings for Different Security Levels
Level of Security |
umask Setting |
Permissions Disallowed |
---|---|---|
Permissive (744) |
022 |
w for group and others |
Moderate (740) |
027 |
w for group, rwx for others |
Moderate (741) |
026 |
w for group, rw for others |
Severe (700) |
077 |
rwx for group and others |
For more information on setting the umask value, see the umask(1) man page.
The chmod command enables you to change the permissions on a file. You must be superuser or the owner of a file or directory to change its permissions.
You can use the chmod command to set permissions in either of two modes:
Absolute Mode – Use numbers to represent file permissions. When you change permissions by using the absolute mode, you represent permissions for each triplet by an octal mode number. Absolute mode is the method most commonly used to set permissions.
Symbolic Mode – Use combinations of letters and symbols to add permissions or remove permissions.
The following table lists the octal values for setting file permissions in absolute mode. You use these numbers in sets of three to set permissions for owner, group, and other, in that order. For example, the value 644 sets read and write permissions for owner, and read-only permissions for group and other.
Table 6–4 Setting File Permissions in Absolute Mode
Octal Value |
File Permissions Set |
Permissions Description |
---|---|---|
0 |
--- |
No permissions |
1 |
--x |
Execute permission only |
2 |
-w- |
Write permission only |
3 |
-wx |
Write and execute permissions |
4 |
r-- |
Read permission only |
5 |
r-x |
Read and execute permissions |
6 |
rw- |
Read and write permissions |
7 |
rwx |
Read, write, and execute permissions |
The following table lists the symbols for setting file permissions in symbolic mode. Symbols can specify whose permissions are to be set or changed, the operation to be performed, and the permissions that are being assigned or changed.
Table 6–5 Setting File Permissions in Symbolic Mode
Symbol |
Function |
Description |
---|---|---|
u |
who |
User (owner) |
g |
who |
Group |
o |
who |
Others |
a |
who |
All |
= |
operator |
Assign |
+ |
operator |
Add |
- |
operator |
Remove |
r |
permissions |
Read |
w |
permissions |
Write |
x |
permissions |
Execute |
l |
permissions |
Mandatory locking, setgid bit is on, group execution bit is off |
s |
permissions |
setuid or setgid bit is on |
t |
permissions |
Sticky bit is on, execution bit for others is on |
The who operator permissions designations in the function column specify the symbols that change the permissions on the file or directory.
Specifies whose permissions are to be changed.
Specifies the operation to be performed.
Specifies what permissions are to be changed.
You can set special permissions on a file in absolute mode or symbolic mode. However, you must use symbolic mode to set or remove setuid permissions on a directory. In absolute mode, you set special permissions by adding a new octal value to the left of the permission triplet. The following table lists the octal values for setting special permissions on a file.
Table 6–6 Setting Special File Permissions in Absolute Mode
Octal Value |
Special File Permissions |
---|---|
1 |
Sticky bit |
2 |
setgid |
4 |
setuid |
Traditional UNIX file protection provides read, write, and execute permissions for the three user classes: file owner, file group, and other. In a UFS file system, an access control list (ACL) provides better file security by enabling you to do the following:
Define file permissions for the file owner, the group, other, specific users and groups
Define default permissions for each of the preceding categories
For ACLs in the ZFS file system and ACLs on NFSv4 files, see Chapter 8, Using ACLs to Protect Oracle Solaris ZFS Files, in Oracle Solaris ZFS Administration Guide.
For example, if you want everyone in a group to be able to read a file, you can simply grant group read permissions on that file. Now, assume that you want only one person in the group to be able to write to that file. Standard UNIX does not provide that level of file security. However, an ACL provides this level of file security.
ACL entries define an ACL on a file. On a UFS file system, the entries are set through the setfacl command. UFS ACL entries consist of the following fields separated by colons:
entry-type:[uid|gid]:perms |
Is the type of ACL entry on which to set file permissions. For example, entry-type can be user (the owner of a file) or mask (the ACL mask). For a listing of ACL entries, see Table 6–7 and Table 6–8.
Is the user name or user ID (UID).
Is the group name or group ID (GID).
Represents the permissions that are set on entry-type. perms can be indicated by the symbolic characters rwx or an octal number. These are the same numbers that are used with the chmod command.
In the following example, an ACL entry sets read and write permissions for the user stacey.
user:stacey:rw- |
UFS file system attributes such as ACLs are supported in UFS file systems only. Thus, if you restore or copy files with ACL entries into the /tmp directory, which is usually mounted as a TMPFS file system, the ACL entries will be lost. Use the /var/tmp directory for temporary storage of UFS files.
The following table lists the valid ACL entries that you might use when setting ACLs on files. The first three ACL entries provide the basic UNIX file protection.
Table 6–7 ACL Entries for UFS Files
ACL Entry |
Description |
---|---|
u[ser]::perms |
File owner permissions. |
g[roup]::perms |
File group permissions. |
o[ther]:perms |
Permissions for users other than the file owner or members of the file group. |
m[ask]:perms |
The ACL mask. The mask entry indicates the maximum permissions that are allowed for users (other than the owner) and for groups. The mask is a quick way to change permissions on all the users and groups. For example, the mask:r-- mask entry indicates that users and groups cannot have more than read permissions, even though their accounts state that they have write and execute permissions. |
u[ser]:uid:perms |
Permissions for a specific user. For uid, you can specify either a user name or a numeric UID. |
g[roup]:gid:perms |
Permissions for a specific group. For gid, you can specify either a group name or a numeric GID. |
In addition to the ACL entries that are described in Table 6–7, you can set default ACL entries on a directory. Files or directories created in a directory that has default ACL entries will have the same ACL entries as the default ACL entries. Table 6–8 lists the default ACL entries for directories.
When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the file owner, file group, others, and the ACL mask. These entries are required. They are the first four default ACL entries in the following table.
Table 6–8 Default ACL Entries for UFS Directories
Default ACL Entry |
Description |
---|---|
d[efault]:u[ser]::perms |
Default file owner permissions. |
d[efault]:g[roup]::perms |
Default file group permissions. |
d[efault]:o[ther]:perms |
Default permissions for users other than the file owner or members of the file group. |
d[efault]:m[ask]:perms |
Default ACL mask. |
d[efault]:u[ser]:uid:perms |
Default permissions for a specific user. For uid, you can specify either a user name or a numeric UID. |
d[efault]:g[roup]:gid:perms |
Default permissions for a specific group. For gid, you can specify either a group name or a numeric GID. |
The following commands administer ACLs on UFS files or directories.
Sets, adds, modifies, and deletes ACL entries. For more information, see the setfacl(1) man page.
Displays ACL entries. For more information, see the getfacl(1) man page.
A number of security bugs are related to default executable stacks when their permissions are set to read, write, and execute. While stacks with execute permissions are allowed, most programs can function correctly without using executable stacks.
The noexec_user_stack variable enables you to specify whether stack mappings are executable. The variable is available as of the Solaris 2.6 release. By default, the variable is set to zero, except on 64-bit applications, which provides ABI-compliant behavior. If the variable is set to a non-zero value, the system marks the stack of every process in the system as readable and writable, but not executable.
Once this variable is set, programs that attempt to execute code on their stack are sent a SIGSEGV signal. This signal usually results in the program terminating with a core dump. Such programs also generate a warning message that includes the name of the offending program, the process ID, and the real UID of the user who ran the program. For example:
a.out[347] attempt to execute code on stack by uid 555 |
The message is logged by the syslog daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf file, which means that the message is sent to both the console and the /var/adm/messages file. For more information, see the syslogd(1M) and syslog.conf(4) man pages.
The syslog message is useful for observing potential security problems. The message also identifies valid programs that depend upon executable stacks that have been prevented from correct operation by setting this variable. If you do not want any messages logged, then set the noexec_user_stack_log variable to zero in the /etc/system file. Even though messages are not being logged, the SIGSEGV signal can continue to cause the executing program to terminate with a core dump.
You can use the mprotect() function if you want programs to explicitly mark their stack as executable. For more information, see the mprotect(2) man page.
Because of hardware limitations, the capability of catching and reporting executable stack problems is not available on most x86-based systems. Systems in the AMD64 product family can catch and report executable stack problems.
The following task map points to sets of procedures for protecting files.
Task |
Description |
For Instructions |
---|---|---|
Use UNIX permissions to protect files |
Views UNIX permissions on files. Protects files with UNIX permissions. | |
Use ACLs to protect files |
Adds ACLs to protect files at a more granular level than UNIX permissions can. | |
Protect system from files that pose a security risk |
Finds executable files that have suspicious ownership. Disables files that can damage the system. |
The following task map points to procedures that list file permissions, change file permissions, and protect files with special file permissions.
Task |
For Instructions |
---|---|
Display file information | |
Change file ownership | |
Change file permissions |
How to Change File Permissions in Symbolic Mode |
Display information about all the files in a directory by using the ls command.
Type the following command to display a long listing of all files in the current directory.
% ls -la |
Displays the long format that includes user ownership, group ownership, and file permissions.
Displays all files, including hidden files that begin with a dot (.).
In the following example, a partial list of the files in the /sbin directory is displayed.
% cd /sbin % ls -la total 13456 drwxr-xr-x 2 root sys 512 Sep 1 14:11 . drwxr-xr-x 29 root root 1024 Sep 1 15:40 .. -r-xr-xr-x 1 root bin 218188 Aug 18 15:17 autopush lrwxrwxrwx 1 root root 21 Sep 1 14:11 bpgetfile -> ... -r-xr-xr-x 1 root bin 505556 Aug 20 13:24 dhcpagent -r-xr-xr-x 1 root bin 456064 Aug 20 13:25 dhcpinfo -r-xr-xr-x 1 root bin 272360 Aug 18 15:19 fdisk -r-xr-xr-x 1 root bin 824728 Aug 20 13:29 hostconfig -r-xr-xr-x 1 root bin 603528 Aug 20 13:21 ifconfig -r-xr-xr-x 1 root sys 556008 Aug 20 13:21 init -r-xr-xr-x 2 root root 274020 Aug 18 15:28 jsh -r-xr-xr-x 1 root bin 238736 Aug 21 19:46 mount -r-xr-xr-x 1 root sys 7696 Aug 18 15:20 mountall . . . |
Each line displays information about a file in the following order:
Type of file – For example, d. For list of file types, see File and Directory Ownership.
Permissions – For example, r-xr-xr-x. For description, see File and Directory Ownership.
Number of hard links – For example, 2.
Owner of the file – For example, root.
Group of the file – For example, bin.
Size of the file, in bytes – For example, 7696.
Date the file was created or the last date that the file was changed – For example, Aug 18 15:20.
Name of the file – For example, mountall.
The file owner, the Primary Administrator role, or superuser can change any file's ownership.
Display the permissions on a file.
% ls -l example-file -rw-r--r-- 1 janedoe staff 112640 May 24 10:49 example-file |
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Change the owner of the file.
# chown stacey example-file |
Verify that the owner of the file has changed.
# ls -l example-file -rw-r--r-- 1 stacey staff 112640 May 26 08:50 example-file |
Security Consideration – You should have good reason to override system security policy by changing the setting of the rstchown variable to zero. Any user who accesses the system can change the ownership of any file on the system.
In this example, the value of the rstchown variable is set to zero in the /etc/system file. This setting enables the owner of a file to use the chown command to change the file's ownership to another user. This setting also enables the owner to use the chgrp command to set the group ownership of a file to a group that the owner does not belong to. The change goes into effect when the system is rebooted.
set rstchown = 0 |
For more information, see the chown(1) and chgrp(1) man pages.
Also, be aware that NFS-mounted file systems have further restrictions on changing ownership and groups. For more information on restricting access to NFS-mounted systems, see Chapter 6, Accessing Network File Systems (Reference), in System Administration Guide: Network Services.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Change the group ownership of a file.
$ chgrp scifi example-file |
For information on setting up groups, see Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration.
Verify that the group ownership of the file has changed.
$ ls -l example-file -rw-r--r-- 1 stacey scifi 112640 June 20 08:55 example-file |
Also see Example 6–2.
If you are not the owner of the file or directory, become superuser or assume an equivalent role.
Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.
Change permissions in symbolic mode.
% chmod who operator permissions filename |
Specifies whose permissions are to be changed.
Specifies the operation to be performed.
Specifies what permissions are to be changed. For the list of valid symbols, see Table 6–5.
Specifies the file or directory.
Verify that the permissions of the file have changed.
% ls -l filename |
In the following example, read permission is taken away from others.
% chmod o-r example-file1 |
In the following example, read and execute permissions are added for user, group, and others.
$ chmod a+rx example-file2 |
In the following example, read, write, and execute permissions are assigned to group.
$ chmod g=rwx example-file3 |
If you are not the owner of the file or directory, become superuser or assume an equivalent role.
Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.
Change permissions in absolute mode.
% chmod nnn filename |
Specifies the octal values that represent the permissions for the file owner, file group, and others, in that order. For the list of valid octal values, see Table 6–4.
Specifies the file or directory.
When you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for other users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.
Verify that the permissions of the file have changed.
% ls -l filename |
In the following example, the permissions of a public directory are changed from 744 (read, write, execute; read-only; and read-only) to 755 (read, write, execute; read and execute; and read and execute).
# ls -ld public_dir drwxr--r-- 1 ignatz staff 6023 Aug 5 12:06 public_dir # chmod 755 public_dir # ls -ld public_dir drwxr-xr-x 1 ignatz staff 6023 Aug 5 12:06 public_dir |
In the following example, the permissions of an executable shell script are changed from read and write to read, write, and execute.
% ls -l my_script -rw------- 1 ignatz staff 6023 Aug 5 12:06 my_script % chmod 700 my_script % ls -l my_script -rwx------ 1 ignatz staff 6023 Aug 5 12:06 my_script |
If you are not the owner of the file or directory, become superuser or assume an equivalent role.
Only the current owner or a user with superuser capabilities can use the chmod command to change the special permissions on a file or directory.
Change special permissions in absolute mode.
% chmod nnnn filename |
Specifies the octal values that change the permissions on the file or directory. The leftmost octal value sets the special permissions on the file. For the list of valid octal values for special permissions, see Table 6–6.
Specifies the file or directory.
When you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for additional users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.
Verify that the permissions of the file have changed.
% ls -l filename |
In the following example, the setuid permission is set on the dbprog file.
# chmod 4555 dbprog # ls -l dbprog -r-sr-xr-x 1 db staff 12095 May 6 09:29 dbprog |
In the following example, the setgid permission is set on the dbprog2 file.
# chmod 2551 dbprog2 # ls -l dbprog2 -r-xr-s--x 1 db staff 24576 May 6 09:30 dbprog2 |
In the following example, the sticky bit permission is set on the public_dir directory.
# chmod 1777 public_dir # ls -ld public_dir drwxrwxrwt 2 ignatz staff 512 May 15 15:27 public_dir |
The following task map points to procedures that list the ACLs on a UFS file, change the ACLs, and copy the ACLs to another file.
Task |
For Instructions |
---|---|
Determine if a file has an ACL | |
Add an ACL to a file | |
Copy an ACL | |
Modify an ACL | |
Remove ACLs from a file | |
Display the ACLs on a file |
% ls -l filename |
where filename specifies the file or directory.
In the output, a plus sign (+) to the right of the mode field indicates that the file has an ACL.
Unless you have added ACL entries that extend UNIX file permissions, a file is considered to have a “trivial” ACL and the plus sign (+) does not display.
In the following example, the ch1.sgm file has an ACL. The ACL is indicated by the plus sign (+) to the right of the mode field.
% ls -l ch1.sgm -rwxr-----+ 1 stacey techpubs 167 Nov 11 11:13 ch1.sgm |
Set an ACL on a file by using the setfacl command.
% setfacl -s user::perms,group::perms,other:perms,mask:perms,acl-entry-list filename ... |
Sets an ACL on the file. If a file already has an ACL, it is replaced. This option requires at least the user::, group::, and other:: entries.
Specifies the file owner permissions.
Specifies the group ownership permissions.
Specifies the permissions for users other than the file owner or members of the group.
Specifies the permissions for the ACL mask. The mask indicates the maximum permissions that are allowed for users (other than the owner) and for groups.
Specifies the list of one or more ACL entries to set for specific users and groups on the file or directory. You can also set default ACL entries on a directory. Table 6–7 and Table 6–8 show the valid ACL entries.
Specifies one or more files or directories on which to set the ACL. Multiple filenames are separated by spaces.
If an ACL already exists on the file, the -s option replaces the entire ACL with the new ACL.
For more information, see the setfacl(1) man page.
Verify that the ACL entries were set on the file.
% getfacl filename |
For more information, see How to Check if a File Has an ACL.
In the following example, the file owner permissions are set to read and write, file group permissions are set to read only, and other permissions are set to none on the ch1.sgm file. In addition, the user anusha is given read and write permissions on the file. The ACL mask permissions are set to read and write, which means that no user or group can have execute permissions.
% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:anusha:rw- ch1.sgm % ls -l total 124 -rw-r-----+ 1 stacey techpubs 34816 Nov 11 14:16 ch1.sgm -rw-r--r-- 1 stacey techpubs 20167 Nov 11 14:16 ch2.sgm -rw-r--r-- 1 stacey techpubs 8192 Nov 11 14:16 notes % getfacl ch1.sgm # file: ch1.sgm # owner: stacey # group: techpubs user::rw- user:anusha:rw- #effective:rw- group::r-- #effective:r-- mask:rw- other:--- |
In the following example, the file owner permissions are set to read, write, and execute, file group permissions are set to read only, other permissions are set to none. In addition, the ACL mask permissions are set to read on the ch2.sgm file. Finally, the user anusha is given read and write permissions. However, due to the ACL mask, the permissions for anusha are read only.
% setfacl -s u::7,g::4,o:0,m:4,u:anusha:7 ch2.sgm % getfacl ch2.sgm # file: ch2.sgm # owner: stacey # group: techpubs user::rwx user:anusha:rwx #effective:r-- group::r-- #effective:r-- mask:r-- other:--- |
Copy a file's ACL to another file by redirecting the getfacl output.
% getfacl filename1 | setfacl -f - filename2 |
Specifies the file from which to copy the ACL.
Specifies the file on which to set the copied ACL.
In the following example, the ACL on ch2.sgm is copied to ch3.sgm.
% getfacl ch2.sgm | setfacl -f - ch3.sgm |
Modify ACL entries on a file by using the setfacl command.
% setfacl -m acl-entry-list filename ... |
Modifies the existing ACL entry.
Specifies the list of one or more ACL entries to modify on the file or directory. You can also modify default ACL entries on a directory. Table 6–7 and Table 6–8 show the valid ACL entries.
Specifies one or more files or directories, separated by a space.
Verify that the ACL entries were modified on the file.
% getfacl filename |
In the following example, the permissions for the user anusha are modified to read and write.
% setfacl -m user:anusha:6 ch3.sgm % getfacl ch3.sgm # file: ch3.sgm # owner: stacey # group: techpubs user::rw- user::anusha:rw- #effective:r-- group::r- #effective:r-- mask:r-- other:r- |
In the following example, the default permissions for the group staff are modified to read on the book directory. In addition, the default ACL mask permissions are modified to read and write.
% setfacl -m default:group:staff:4,default:mask:6 book |
Delete ACL entries from a file.
% setfacl -d acl-entry-list filename ... |
Deletes the specified ACL entries.
Specifies the list of ACL entries (without specifying the permissions) to delete from the file or directory. You can only delete ACL entries and default ACL entries for specific users and groups. Table 6–7 and Table 6–8 show the valid ACL entries.
Specifies one or more files or directories, separated by a space.
Alternatively, you can use the setfacl -s command to delete all the ACL entries on a file and replace them with the new ACL entries that are specified.
Verify that the ACL entries were deleted from the file.
% getfacl filename |
In the following example, the user anusha is deleted from the ch4.sgm file.
% setfacl -d user:anusha ch4.sgm |
Display ACL entries for a file by using the getfacl command.
% getfacl [-a | -d] filename ... |
Displays the file name, file owner, file group, and ACL entries for the specified file or directory.
Displays the file name, file owner, file group, and the default ACL entries, if they exist, for the specified directory.
Specifies one or more files or directories, separated by a space.
If you specify multiple file names on the command line, the ACL entries are displayed with a blank line between each entry.
In the following example, all the ACL entries for the ch1.sgm file are displayed. The #effective: note beside the user and group entries indicates what the permissions are after being modified by the ACL mask.
% getfacl ch1.sgm # file: ch1.sgm # owner: stacey # group: techpubs user::rw- user:anusha:r- #effective:r-- group::rw- #effective:rw- mask:rw- other:--- |
In the following example, the default ACL entries for the book directory are displayed.
% getfacl -d book # file: book # owner: stacey # group: techpubs user::rwx user:anusha:r-x #effective:r-x group::rwx #effective:rwx mask:rwx other:--- default:user::rw- default:user:anusha:r-- default:group::rw- default:mask:rw- default:other:--- |
The following task map points to procedures that find risky executables on the system, and that prevent programs from exploiting an executable stack.
Task |
Description |
For Instructions |
---|---|---|
Find files with special permissions |
Locates files with the setuid bit set, but that are not owned by the root user. | |
Prevent executable stack from overflowing |
Prevents programs from exploiting an executable stack. | |
Prevent logging of executable stack messages |
Turns off logging of executable stack messages. |
You should monitor your system for any unauthorized use of the setuid and setgid permissions on programs. The setuid and setgid permissions enable ordinary users to gain superuser capabilities. A suspicious executable file grants ownership to a user rather than to root or bin.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Find files with setuid permissions by using the find command.
# find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename |
Checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail.
Displays files owned only by root.
Displays files only with permissions set to 4000.
Displays the output of the find command in ls -ldb format.
Is the file that contains the results of the find command.
Display the results in /tmp/filename.
# more /tmp/filename |
For background information on setuid permissions, see setuid Permission.
The output from the following example shows that a user named rar has made a personal copy of /usr/bin/sh, and has set the permissions as setuid to root. As a result, the /usr/rar/bin/sh program runs with root permissions.
This output was saved for future reference by moving the file out of the /tmp directory.
# find / -user root -perm -4000 -exec ls -ldb {} \; > /var/tmp/ckprm # cat /var/tmp/ckprm -r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at -r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab ---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct -r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir -r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin -r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched ---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh -r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df -rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp -r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd -r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su # mv /var/tmp/ckprm /export/sysreports/ckprm |
For a description of the security risks of executable stacks, see Preventing Executable Files From Compromising Security.
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Edit the /etc/system file, and add the following line:
set noexec_user_stack=1 |
Reboot the system.
# init 6 |
In this example, the logging of executable stack messages is disabled, and then the system is rebooted.
# cat /etc/system set noexec_user_stack=1 set noexec_user_stack_log=0 # init 6 |
This chapter describes how to use the Automated Security Enhancement Tool (ASET) to monitor or restrict access to system files and directories.
The following is a list of the step-by-step instructions in this chapter.
For a more comprehensive tool than ASET, use the Sun Security Toolkit. The Sun Security Toolkit provides a framework for hardening and minimizing a Solaris system. The kit includes a profiling tool, a reporting tool, and an undo capability. The toolkit is free, and can be downloaded from the Sun web site, http://www.sun.com/software/security/jass. The web site contains pointers to online documentation.
The toolkit is described in detail in Securing Systems with the Solaris Security Toolkit, by Alex Noordergraaf and Glenn Brunette, ISBN 0-13-141071-7, June 2003. The book is part of the Sun BluePrints Series, which is published by Sun Microsystems Press.
The Solaris Operating System includes the Automated Security Enhancement Tool (ASET). ASET helps you to monitor and to control system security by automatically performing tasks that you would otherwise do manually.
The ASET security package provides automated administration tools that enable you to control and monitor your system's security. You specify a security level at which to run ASET. The security levels are low, medium, and high. At each higher level, ASET's file-control functions increase to reduce file access and tighten your system security.
There are seven tasks that ASET runs. Each task performs specific checks and adjustments to system files. The ASET tasks tighten file permissions, check the contents of critical system files for security weaknesses, and monitor crucial areas. ASET can also safeguard a network by applying the basic requirements of a firewall system to a system that serves as a gateway system. See Firewall Setup.
ASET uses master files for configuration. Master files, reports, and other ASET files are in the /usr/aset directory. These files can be changed to suit the particular requirements of your site.
Each task generates a report. The report notes detected security weaknesses and any changes that the task has made to the system files. When run at the highest security level, ASET attempts to modify all system security weaknesses. If ASET cannot correct a potential security problem, ASET reports the existence of the problem.
You can initiate an ASET session by using the /usr/aset/aset command interactively. Or, you can set up ASET to run periodically by putting an entry into the crontab file.
ASET tasks are disk-intensive. The tasks can interfere with regular activities. To minimize the impact on system performance, schedule ASET to run when system activity level is lowest. For example, run ASET once every 24 or 48 hours at midnight.
ASET can be set to operate at one of three security levels: low, medium, or high. At each higher level, ASET's file-control functions increase to reduce file access and heighten system security. These functions range from monitoring system security without limiting users' file access, to increasingly tightening access permissions until the system is fully secured.
The following table outlines these three levels of security.
ASET does not change the permissions of a file to make the file less secure, unless you downgrade the security level. You could also intentionally revert the system to the settings that existed prior to running ASET.
This section discusses what ASET does. You should understand each ASET task. By understanding the objectives of ASET, the operations that ASET performs, and the system components that ASET affects, you can interpret and use the reports effectively.
ASET report files contain messages that describe as specifically as possible any problems that were discovered by each ASET task. These messages can help you diagnose and correct these problems. However, successful use of ASET assumes that you possess a general understanding of system administration and system components. If you are a novice administrator, you can refer to other Solaris system administration documentation. You can read related manual pages to prepare yourself for ASET administration.
The taskstat utility identifies the tasks that have been completed. The utility also identifies the tasks that are still running. Each completed task produces a report file. For a complete description of the taskstat utility, refer to taskstat(1M).
This task sets the permissions on system files to the security level that you designate. This task is run when the system is installed. If you decide later to alter the previously established levels, then run this task again. At low security, permissions are set to values that are appropriate for an open information-sharing environment. At medium security, permissions are tightened to produce adequate security for most environments. At high security, permissions are tightened to severely restrict access.
Any modifications that this task makes to system files permissions or parameter settings are reported in the tune.rpt file. For an example of the files that ASET consults when ASET sets permissions, see Tune File Examples.
This task examines system files and compares each file with a description of that file in a master file. The master file is created the first time ASET runs this task. The master file contains the system file settings that are enforced by checklist for the specified security level.
A list of directories whose files are to be checked is defined for each security level. You can use the default list, or you can modify the list, specifying different directories for each level.
For each file, the following criteria are checked:
Owner and group
Permission bits
Size and checksum
Number of links
Last modification time
Any discrepancies that ASET finds are reported in the cklist.rpt file. This file contains the results of comparing system file size, permission, and checksum values to the master file.
This task checks the consistency and integrity of user accounts and groups. The task uses the definitions in the passwd and group files. This task checks the local, and NIS or NIS+ password files. Password file problems for NIS+ are reported but not corrected.
his task checks for the following violations:
Duplicate names or IDs
Entries in incorrect format
Accounts without a password
Invalid login directories
The nobody account
Null group password
A plus sign (+) in the /etc/passwd file on an NIS server or an NIS+ server
Discrepancies are reported in the usrgrp.rpt file.
During this task, ASET checks various system tables, most of which are in the /etc directory.
These files are the following:
/etc/default/login
/etc/hosts.equiv
/etc/inetd.conf
/etc/aliases
/var/adm/utmpx
/.rhosts
/etc/vfstab
/etc/dfs/dfstab
/etc/ftpd/ftpusers
ASET performs various checks and various modifications on these files. ASET reports problems in the sysconf.rpt file.
This task checks how the PATH and UMASK environment variables are set for root, and for other users. The task checks the /.profile, /.login, and /.cshrc files.
The results of checking the environment for security are reported in the env.rpt file.
This task checks the value of the eeprom security parameter to ensure that the parameter is set to the appropriate security level. You can set the eeprom security parameter to none, command, or full.
ASET does not change this setting, but reports its recommendations in the eeprom.rpt file.
This task ensures that the system can be safely used as a network relay. This task protects an internal network from external public networks by setting up a dedicated system as a firewall, which is described in Firewall Systems. The firewall system separates two networks. In this situation, each network approaches the other network as untrusted. The firewall setup task disables the forwarding of Internet Protocol (IP) packets. The firewall also hides routing information from the external network.
The firewall task runs at all security levels, but takes action only at the highest level. If you want to run ASET at high security, but find that your system does not require firewall protection, you can eliminate the firewall task. You eliminate the task by editing the asetenv file.
Any changes that are made are reported in the firewall.rpt file.
ASET generates an execution log whether ASET runs interactively or in the background. By default, ASET generates the log file on standard output. The execution log confirms that ASET ran at the designated time, and also contains any execution error messages. The aset -n command directs the log to be delivered by electronic mail to a designated user. For a complete list of ASET options, see the aset(1M) man page.
ASET running at security level low Machine=example; Current time = 0325_08:00 aset: Using /usr/aset as working directory Executing task list... firewall env sysconfig usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: $/usr/aset/util/taskstat aset_dir Where aset_dir is ASET's operating directory, currently=/usr/aset When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt |
The execution log first shows the system and time that ASET was run. Then, the execution log lists each task as the task was started.
ASET invokes a background process for each of these tasks, which are described in ASET Task List. The task is listed in the execution log when the task starts. This listing does not indicate that the task completed. To check the status of the background tasks, use the taskstat command.
All report files that are generated from ASET tasks are stored in subdirectories under the /usr/aset/reports directory. This section describes the structure of the /usr/aset/reports directory, and provides guidelines on managing the report files.
ASET places the report files in subdirectories that are named to reflect the time and date when the reports are generated. This convention enables you to keep an orderly trail of records that document the system status as the status varies between ASET executions. You can monitor and compare these reports to determine the soundness of your system's security.
The following figure shows an example of the reports directory structure.
This example shows two report subdirectories.
0124_01:00
0125_01:00
The subdirectory names indicate the date and time that the reports were generated. Each report subdirectory name has the following format:
monthdate_hour:minute |
month, date, hour, and minute are all two-digit numbers. For example, 0125_01:00 represents January 25, at 1 a.m.
Each of the two report subdirectories contains a collection of reports that are generated from one execution of ASET.
The latest directory is a symbolic link that always points to the subdirectory that contains the latest reports. Therefore, to look at the latest reports that ASET has generated, you can go to the /usr/aset/reports/latest directory. There is a report file in this directory for each task that ASET performed during its most recent execution.
Each report file is named after the task that generates the report. The following table lists tasks and their reports.
Table 7–1 ASET Tasks and Resulting Reports
Tasks |
Report |
---|---|
System files permissions tuning (tune) |
tune.rpt |
System files checks (cklist) |
cklist.rpt |
User and group checks (usrgrp) |
usrgrp.rpt |
System configuration files check (sysconf) |
sysconf.rpt |
Environment variables check (env) |
env.rpt |
eeprom check (eeprom) |
eeprom.rpt |
Firewall setup (firewall) |
firewall.rpt |
Within each report file, messages are bracketed by a beginning and an ending banner line. Sometimes, a task ends prematurely. For example, a task can end prematurely when a component of ASET is accidentally removed or damaged. In such cases, the report file usually contains a message near the end that indicates the reason for the premature termination.
The following is a sample report file, usrgrp.rpt.
*** Begin User and Group Checking *** Checking /etc/passwd ... Warning! Password file, line 10, no passwd :sync::1:1::/:/bin/sync ..end user check; starting group check ... Checking /etc/group... *** End User And group Checking *** |
After you initially run or reconfigure ASET, you should examine the report files closely. Reconfiguration includes modifying the asetenv file or the master files in the masters subdirectory, or changing the security level at which ASET operates.
The reports record any errors that were introduced when you reconfigured ASET. By watching the reports closely, you can react to, and solve, problems as the problems arise.
After you monitor the report files for a period during which there are no configuration changes or system updates, you might find that the content of the reports begins to stabilize. When the reports contain little unexpected information, you can use the diff utility to compare reports.
ASET's master files, tune.high, tune.low, tune.med, and uid_aliases, are located in the /usr/aset/masters directory. ASET uses the master files to define security levels. For more detail, see the asetmasters(4) man page.
The tune.low, tune.med, and tune.high master files define the available ASET security levels. The files specify the attributes of system files at each level and are used for comparison and reference purposes.
The uid_aliases file contains a list of multiple user accounts that share the same user ID (UID). Normally, ASET warns about such multiple user accounts because this practice lessens accountability. You can allow for exceptions to this rule by listing the exceptions in the uid_aliases file. ASET does not report entries in the passwd file with duplicate UIDs if these entries are specified in the uid_aliases file.
Avoid having multiple user accounts share the same UID. You should consider other methods of achieving your objective. For example, if you intend for several users to share a set of permissions, you could create a group account. You could also create a role. The sharing of UIDs should be your last resort, used only when other methods cannot accomplish your objectives.
You can use the UID_ALIASES environment variable to specify an alternate aliases file. The default file is /usr/aset/masters/uid_aliases.
The master files that are used by the system files checks are generated when you first execute ASET. The master files are also generated when you run ASET after changing the security level.
The following environment variables define the files that are checked by this task:
CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH
The environment file, asetenv, contains a list of environment variables that affect ASET tasks. Some of these variables can be changed to modify ASET operation. For details about the asetenv file, see asetenv(4).
This section discusses how ASET is configured. This section also discusses the environment in which ASET operates.
ASET requires minimum administration and minimum configuration. In most cases, you can run ASET with the default values. You can, however, fine-tune some of the parameters that affect the operation and behavior of ASET to maximize its benefit. Before you change the default values, you should understand how ASET works, and how ASET affects the components of your system.
ASET relies on four configuration files to control the behavior of its tasks:
/usr/aset/asetenv
/usr/aset/masters/tune.low
/usr/aset/masters/tune.med
/usr/aset/masters/tune.high
The /usr/aset/asetenv file has two main sections:
A user-configurable environment variables section
An internal environment variables section
You can alter the user-configurable parameters section. However, the settings in the internal environment variables section are for internal use only. These settings should not be modified.
You can edit the entries in the user-configurable section to do the following:
Choose which tasks to run
Specify the directories for the system files checks task
Schedule ASET execution
Specify a UID aliases file
Extend checks to NIS+ tables
Each task that ASET performs monitors a particular area of system security. In most system environments, all the tasks are necessary to provide balanced security coverage. However, you might decide to eliminate one or more tasks.
For example, the firewall task runs at all security levels, but takes action only at the high security level. You might want to run ASET at the high security level, but you do not require firewall protection.
You can set up ASET to run at the high security level without the firewall feature. To do so, edit the TASKS list of environment variables in the asetenv file. By default, the TASKS list contains all of the ASET tasks. To delete a task, remove the task-related environment variable from the file. In this case, you would delete the firewall environment variable from the list. The next time ASET runs, the excluded task is not performed.
In the following example, the TASKS list with all of the ASET tasks is displayed.
TASKS=”env sysconfig usrgrp tune cklist eeprom firewall” |
The system files check checks the attributes of files in selected system directories. You define which directories to check by using the following environment variables.
The CKLISTPATH_LOW variable defines the directories to be checked at the low security level. CKLISTPATH_MED and CKLISTPATH_HIGH environment variables function similarly for the medium and high security levels.
The directory list that is defined by an environment variable at a lower security level should be a subset of the directory list that is defined at the next higher level. For example, all directories that are specified for CKLISTPATH_LOW should be included in CKLISTPATH_MED. Similarly, all the directories that are specified for CKLISTPATH_MED should be included in CKLISTPATH_HIGH.
Checks that are performed on these directories are not recursive. ASET only checks those directories that are explicitly listed in the environment variable. ASET does not check their subdirectories.
You can edit these environment variable definitions to add or delete directories that you want ASET to check. Note that these checklists are useful only for system files that do not normally change from day to day. A user's home directory, for example, is generally too dynamic to be a candidate for a checklist.
You can start ASET interactively, or you can use the -p option to request that the ASET tasks run at a scheduled time. You can run ASET periodically, at a time when system demand is light. For example, ASET consults PERIODIC_SCHEDULE to determine how frequently to execute the ASET tasks, and at what time to run the tasks. For detailed instructions about setting up ASET to run periodically, see How to Run ASET Periodically.
The format of PERIODIC_SCHEDULE follows the format of crontab entries. For complete information, see crontab(1).
The UID_ALIASES variable specifies an aliases file that lists shared UIDs. The default file is /usr/aset/masters/uid_aliases.
The YPCHECK environment variable specifies whether ASET should also check system configuration file tables. YPCHECK is a Boolean variable. You can specify only true or false for YPCHECK. The default value is false, which disables NIS+ table checking.
To understand how this environment variable works, consider its effect on the passwd file. When set to false, ASET checks the local passwd file. When set to true, the task also checks the NIS+ passwd table for the domain of the system.
Although ASET automatically repairs the local files, ASET only reports potential problems in the NIS+ tables. ASET does not change the tables.
ASET uses the three master tune files, tune.low, tune.med, and tune.high, to ease or tighten access to critical system files. These master files are located in the /usr/aset/masters directory. You can modify the files to suit your environment. For examples, see Tune File Examples.
The tune.low file sets permissions to values that are appropriate for default system settings. The tune.med file further restricts these permissions. The tune.med file also includes entries that are not present in tune.low. The tune.high file restricts permissions even further.
Modify settings in the tune files by adding or deleting file entries. You cannot effectively set a permission to a less restrictive value than the current setting. The ASET tasks do not relax permissions unless you downgrade your system security to a lower level.
When ASET is executed for the first time, ASET saves and archives the original system files. The aset.restore utility reinstates these files. This utility also deschedules ASET, if ASET is currently scheduled for periodic execution. The aset.restore command is located in /usr/aset, the ASET operating directory.
Changes that are made to system files are lost when you run the aset.restore command.
You should use the aset.restore command in the following instances:
When you want to remove ASET changes and to restore the original system.
If you want to deactivate ASET permanently, you can remove ASET from cron scheduling if the aset command had previously been added to root's crontab. For instructions on how to use cron to remove automatic execution, see How to Stop Running ASET Periodically.
After a brief period of experimenting with ASET, to restore the original system state.
When some major system feature is not working properly, and you suspect that ASET is causing the problem.
Generally, ASET is used in standalone mode, even on a system that is part of a network. As system administrator for your standalone system, you are responsible for the security of your system. Therefore, you are responsible for running and managing ASET to protect your system.
You can also use ASET in the NFS distributed environment. As a network administrator, you are responsible for installing, running, and managing various administrative tasks for all your clients. To facilitate ASET management across several client systems, you can make configuration changes that are applied globally to all clients. By globally applying changes, you eliminate the need to log in to each system to repeat the configuration changes.
When you are deciding how to set up ASET on your networked systems, you should consider who you want to control security. You might want users to control some security on their own systems. You might want to centralize responsibility for security control.
A situation might arise where you want to set up more than one network configuration. For example, you might want to set up one configuration for clients that are designated with low security level. You might want to set up another configuration for medium level clients, and yet another configuration with high level.
If you need to create a separate ASET network configuration for each security level, you can create three ASET configurations on the server. You create one configuration for each level. You would export each configuration to the clients with the appropriate security level. Some ASET components that are common to all three configurations could be shared by using links.
Not only can you centralize the ASET components on a server, but you can also set up a central directory on a server to collect all ASET reports. The server can be accessed by clients with or without superuser privileges. For instructions on setting up a collection mechanism, see How to Collect ASET Reports on a Server.
By setting up the collection of reports on a server, you can review reports for all clients from one location. You can use this method whether or not a client has superuser privileges. Alternatively, you can leave the reports directory on the local system when you want users to monitor their own ASET reports.
The following is a list of the ASET environment variables and the values that the variables specify.
Specifies the ASET working directory
Specifies the security level
Specifies the periodic schedule
Specifies which ASET tasks to run
Specifies an aliases file
Determines whether to extend checks to NIS maps and NIS+ tables
Is the directory list for low security
Is the directory for medium security
Is the directory list for high security
The environment variables that are listed in the following sections are found in the /usr/aset/asetenv file. The ASETDIR and ASETSECLEVEL variables are optional. The variables can be set only through the shell by using the /usr/aset/aset command. The other environment variables can be set by editing the file.
ASETDIR specifies an ASET working directory.
From the C shell, type:
% setenv ASETDIR pathname |
From the Bourne shell or the Korn shell, type:
$ ASETDIR=pathname $ export ASETDIR |
Set pathname to the full path name of the ASET working directory.
The ASETSECLEVEL variable specifies a security level at which ASET tasks are executed.
From the C shell, type:
% setenv ASETSECLEVEL level |
From the Bourne shell or the Korn shell, type:
$ ASETSECLEVEL=level $ export ASETSECLEVEL |
In these commands, level can be set to one of the following:
Low security level
Medium security level
High security level
The value of PERIODIC_SCHEDULE follows the same format as the crontab file. Specify the variable value as a string of five fields enclosed in double quotation marks, with each field separated by a space:
"minutes hours day-of-month month day-of-week" |
Specifies start time in number of minutes (0-59) after the hour and the hour (0-23).
Specifies the day of the month when ASET should be run, with values from 1-31.
Specifies the month of the year when ASET should be run, with values from 1-12.
Specifies the day of the week when ASET should be run, with values from 0-6. Sunday is day 0.
The following rules apply when creating a periodic schedule for ASET:
You can specify a list of values, each delimited by a comma, for any field.
You can specify a value as a number, or you can specify the value as a range. A range is a pair of numbers that are joined by a hyphen. A range states that the ASET tasks should be executed for every time that is included in the range.
You can specify an asterisk (*) as the value of any field. An asterisk inclusively specifies all possible values of the field.
The default entry for the PERIODIC_SCHEDULE variable causes ASET to execute at 12:00 midnight every day:
PERIODIC_SCHEDULE=”0 0 * * *” |
The TASKS variable lists the tasks that ASET performs. The default is to list all seven tasks:
TASKS=”env sysconfig usrgrp tune cklist eeprom firewall” |
The UID_ALIASES variable specifies an aliases file. If present, ASET consults this file for a list of permitted multiple aliases. The format is UID_ALIASES=pathname, where pathname is the full path name of the aliases file.
The default is as follows:
UID_ALIASES=${ASETDIR}/masters/uid_aliases |
The YPCHECK variable extends the task of checking system tables to include NIS or NIS+ tables. The YPCHECK variable is a Boolean variable, which can be set to either true or false.
The default is false, which confines the checking to local system tables:
YPCHECK=false |
The three checklist path variables list the directories to be checked by the system files checks task. The following definitions of the variables are set by default. The definitions illustrate the relationship between the variables at different levels:
CKLISTPATH_LOW=${ASETDIR}/tasks:${ASETDIR}/util:${ASETDIR}/masters:/etc CKLISTPATH_MED=${CKLISTPATH_LOW}:/usr/bin:/usr/ucb CKLISTPATH_HIGH=${CKLISTPATH_MED}:/usr/lib:/sbin:/usr/sbin:/usr/ucblib |
The values for the checklist path environment variables are similar to the values of the shell path variables. Like the shell path variables, the checklist path environment variables are lists of directory names. The directory names are separated by colons. You use an equal sign (=) to connect the variable name to its value.
This section has examples of some ASET files, including the tune files and the aliases file.
ASET maintains three tune files. Each entry in a tune file occupies one line. The fields in an entry are in the following order:
pathname mode owner group type |
The full path name of the file
A five-digit number that represents the permission setting
The owner of the file
The group owner of the file
The type of file
The following rules apply when you edit the tune files:
You can use regular shell wildcard characters, such as an asterisk (*) and a question mark (?), in the path name for multiple references. For more information, see sh(1).
mode represents the least restrictive value. If the current setting is already more restrictive than the specified value, ASET does not loosen the permission settings. For example, if the specified value is 00777, the permission remains unchanged, because 00777 is always less restrictive than whatever the current setting is.
This process is how ASET handles mode setting. The process is different if the security level is being downgraded, or if you are removing ASET. When you decrease the security level from the level in the previous execution, or when you want to restore the system files to the state they were in before ASET was first executed, ASET recognizes what you are doing and decreases the protection level.
You must use names for owner and group instead of numeric IDs.
You can use a question mark (?) in place of owner, group, and type to prevent ASET from changing the existing values of these parameters.
type can be symlink, directory, or file. A symlink is a symbolic link.
Higher security level tune files reset file permissions to be at least as restrictive as file permissions at lower levels. Also, at higher security levels, additional files are added to the list.
A file can match more than one tune file entry. For example, etc/passwd matches the etc/pass* and /etc/* entries.
Where two entries have different permissions, the file permission is set to the most restrictive value. In the following example, the permission of the /etc/passwd file is set to 00755, which is the more restrictive of 00755 and 00770.
/etc/pass* 00755 ? ? file /etc/* 00770 ? ? file |
If two entries have different owner designations or group designations, the last entry takes precedence. In the following example, the owner of /usr/sbin/chroot is set to root.
/usr/sbin/chroot 00555 bin bin file /usr/sbin/chroot 00555 root bin file |
The aliases file contains a list of aliases that share the same user ID.
Each entry is in this form:
uid=alias1=alias2=alias3=...
Shared UID.
User accounts that share a UID.
For example, the following entry lists the UID 0. The UID is being shared by the sysadm and root accounts:
0=root=sysadm
Task |
Description |
For Instructions |
---|---|---|
Run ASET from the command line |
Protects the system at the ASET level that you specify. Views the execution log to see the changes. | |
Run ASET in batch mode at regular intervals |
Sets up a cron job to ensure that ASET protects the system. | |
Stop running ASET in batch mode |
Removes the ASET cron job. | |
Store ASET reports on a server |
Collects ASET reports from clients for monitoring in a central location. |
To set the variables in ASET, see ASET Environment Variables. To configure ASET, see Configuring ASET.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).
Run ASET interactively by using the aset command.
# /usr/aset/aset -l level -d pathname |
Specifies the level of security. Valid values are low, medium, or high. The default setting is low. For detailed information about security levels, see ASET Security Levels.
Specifies the working directory for ASET. The default is /usr/aset.
Verify that ASET is running by viewing the ASET execution log that is displayed on the screen.
The execution log message identifies which tasks are being run.
In the following example, ASET is run at low security with the default working directory.
# /usr/aset/aset -l low ======= ASET Execution Log ======= ASET running at security level low Machine = jupiter; Current time = 0111_09:26 aset: Using /usr/aset as working directory Executing task list ... firewall env sysconf usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: /usr/aset/util/taskstat [aset_dir] where aset_dir is ASET's operating directory,currently=/usr/aset. When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt |
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).
If necessary, set up the time when you want ASET to run periodically.
You should have ASET run when system demand is light. The PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file is used to set up the time for ASET to run periodically. By default, the time is set for every day at midnight.
If you want to set up a different time, edit the PERIODIC_SCHEDULE variable in the /usr/aset/asetenv file. For detailed information about setting the PERIODIC_SCHEDULE variable, see PERIODIC_SCHEDULE Environment Variable.
Add an entry to the crontab file by using the aset command.
# /usr/aset/aset -p |
The -p option inserts a line in the crontab file that starts ASET running at the time determined by the PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file.
Display the crontab entry to verify when ASET is scheduled to run.
# crontab -l root |
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Edit the crontab file.
# crontab -e root |
Delete the ASET entry.
Save the changes and exit.
Display the crontab entry to verify that the ASET entry is deleted.
# crontab -l root |
Assume the Primary Administrator role, or become superuser.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Set up a directory on the server:
Change to the /usr/aset directory.
mars# cd /usr/aset |
Create a rptdir directory.
mars# mkdir rptdir |
Change to the rptdir directory, and create a client_rpt directory.
This step creates a client_rpt subdirectory for a client. Repeat this step for each client whose reports you need to collect.
mars# cd rptdir mars# mkdir client_rpt |
In the following example, the directory all_reports, and the subdirectories pluto_rpt and neptune_rpt are created.
mars# cd /usr/aset mars# mkdir all_reports mars# cd all_reports mars# mkdir pluto_rpt mars# mkdir neptune_rpt |
Add the client_rpt directories to the /etc/dfs/dfstab file.
The directories should have read and write options.
For example, the following entries in the dfstab file are shared with read and write permissions.
share -F nfs -o rw=pluto /usr/aset/all_reports/pluto_rpt share -F nfs -o rw=neptune /usr/aset/all_reports/neptune_rpt |
Make the resources in the dfstab file available to the clients.
# shareall |
On each client, mount the client subdirectory from the server at the mount point, /usr/aset/masters/reports.
# mount server:/usr/aset/client_rpt /usr/aset/masters/reports |
Edit the /etc/vfstab file to mount the directory automatically at boot time.
The following sample entry in /etc/vfstab on neptune lists the directory to be mounted from mars, /usr/aset/all_reports/neptune_rpt, and the mount point on neptune, /usr/aset/reports. At boot time, the directories that are listed in vfstab are automatically mounted.
mars:/usr/aset/all_reports/neptune.rpt /usr/aset/reports nfs - yes hard |
This section describes the error messages that are generated by ASET.
ASET failed: no mail program found.
Cause:ASET is directed to send the execution log to a user, but no mail program can be found.
Solution:Install a mail program.
Usage: aset [-n user[@host]] in /bin/mail or /usr/ucb/mail.
Cannot decide current and previous security levels.
Cause:ASET cannot determine what the security levels are for the current and previous invocations.
Solution:Ensure the current security level is set either through the command-line option or the ASETSECLEVEL environment variable. Also, ensure that the last line of ASETDIR/archives/asetseclevel.arch correctly reflects the previous security level. If these values are not set, or if these values are incorrect, enter the correct values.
ASET working directory undefined.
To specify, set ASETDIR environment variable or use command line option -d.
ASET startup unsuccessful.
Cause:The ASET working directory is not defined, or the directory is defined incorrectly. The working directory is the operating directory.
Solution:Use the ASETDIR environment variable or the -d command-line option to correct the error, and restart ASET.
ASET working directory $ASETDIR missing.
ASET startup unsuccessful.
Cause:The ASET working directory is not defined, or the directory is defined incorrectly. The working directory is the operating directory. This problem might be because the ASETDIR variable refers to a nonexistent directory. Or the -d command-line option might refer to a nonexistent directory.
Solution:Ensure that the correct directory, that is, the directory that contains the ASET directory hierarchy, is referred to correctly.
Cannot expand $ASETDIR to full pathname.
Cause:ASET cannot expand the directory name that is given by the ASETDIR variable or the -d command-line option to a full path name.
Solution:Ensure that the directory name is correct. Ensure that the directory refers to an existing directory to which the user has access.
aset: invalid/undefined security level.
To specify, set ASETSECLEVEL environment variable or use command line option -l, with argument= low/med/high.
Cause:The security level is not defined, or the level is defined incorrectly. Only the values low, med, or high are acceptable.
Solution:Use the ASETSECLEVEL variable or the -l command-line option to specify one of the three values.
ASET environment file asetenv not found in $ASETDIR.
ASET startup unsuccessful.
Cause:ASET cannot locate an asetenv file in its working directory.
Solution:Ensure there is an asetenv file in ASET's working directory. For the details about this file, see the asetenv(4) man page.
filename doesn't exist or is not readable.
Cause:The file that is referred to by filename either does not exist or is not readable. This problem can occur when you are using the -u option. The option permits you to specify a file that contains a list of users whom you want to check.
Solution:Ensure that the argument to the -u option exists and that the argument is readable.
ASET task list TASKLIST undefined.
Cause:The ASET task list, which should be defined in the asetenv file, is not defined. This message can mean that your asetenv file is bad.
Solution:Examine your asetenv file. Ensure that the task list is defined in the User Configurable section. Also check other parts of the file to ensure that the file is intact. For the content of a valid asetenv file, see the asetenv(4) man page.
ASET task list $TASKLIST missing.
ASET startup unsuccessful.
Cause:The ASET task list, which should be defined in the asetenv file, is not defined. This message can mean that your asetenv file is bad.
Solution:Examine your asetenv file. Ensure that the task list is defined in the User Configurable section. Also check other parts of the file to ensure that the file is intact. For the content of a valid asetenv file, see the asetenv(4) man page.
Schedule undefined for periodic invocation.
No tasks executed or scheduled. Check asetenv file.
Cause:ASET scheduling is requested by using the -p option, but the environment variable PERIODIC_SCHEDULE is undefined in the asetenv file.
Solution:Check the User Configurable section of the asetenv file to ensure that the variable is defined. Ensure that the variable is in proper format.
Warning! Duplicate ASET execution scheduled.
Check crontab file.
Cause:ASET is scheduled to run more than once. In other words, ASET scheduling is requested while a schedule is already in effect. This message does not necessarily indicate an error if more than one schedule is indeed desired. In this instance, the messages servers only as a warning. If you want more than one schedule, you should use the proper scheduling format with the crontab command. For more information, see the crontab(1) man page.
Solution:Verify, through the crontab command, that the correct schedule is in effect. Ensure that no unnecessary crontab entries for ASET are in place.