Part II System, File, and Device Security

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.

Chapter 2 Managing Machine Security (Overview)

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.

• Enhancements to Machine Security in the Solaris 10 Release

• Controlling Access to a Computer System

• Controlling Access to Devices

• Controlling Access to Machine Resources

• Controlling Access to Files

• Controlling Network Access

• Reporting Security Problems

Enhancements to Machine Security in the Solaris 10 Release

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.

Controlling Access to a Computer System

In the workplace, all machines that are connected to a server can be thought of as one large multifaceted system. You are responsible for the security of this larger system. You need to defend the network from outsiders who are trying to gain access to the network. You also need to ensure the integrity of the data on the machines within the network.

At the file level, the Solaris OS provides standard security features that you can use to protect files, directories, and devices. At the system and network levels, the security issues are mostly the same. The first line of security defense is to control access to your system.

You can control and monitor system access by doing the following:

• Maintaining Physical Security

• Maintaining Login Control

• Controlling Access to Devices

• Controlling Access to Machine Resources

• Controlling Access to Files

• Controlling Network Access

• Reporting Security Problems

Maintaining Physical Security

To control access to your system, you must maintain the physical security of your computing environment. For instance, a system that is logged in and left unattended is vulnerable to unauthorized access. An intruder can gain access to the operating system and to the network. The computer's surroundings and the computer hardware should be physically protected from unauthorized access.

You can protect a SPARC system from unauthorized access to the hardware settings. Use the eeprom command to require a password to access the PROM. For more information, see How to Require a Password for Hardware Access.

Maintaining Login Control

You also must prevent unauthorized logins to a system or the network, which you can do through password assignment and login control. All accounts on a system should have a password. A password is a simple authentication mechanism. An account without a password makes your entire network accessible to an intruder who guesses a user name. A strong password algorithm protects against brute force attacks.

When a user logs in to a system, the login command checks the appropriate name service or directory service database according to the information that is listed in the /etc/nsswitch.conf file. This file can include the following entries:

• files – Designates the /etc files on the local system

• ldap – Designates the LDAP directory service on the LDAP server

• nis – Designates the NIS database on the NIS master server

• nisplus – Designates the NIS+ database on the NIS+ root server

For a description of the nsswitch.conf file, see the nsswitch.conf(4) man page. For information about naming services and directory services, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (NIS+).

The login command verifies the user name and password that were supplied by the user. If the user name is not in the password file, the login command denies access to the system. If the password is not correct for the user name that was specified, the login command denies access to the system. When the user supplies a valid user name and its corresponding password, the system grants the user access to the system.

PAM modules can streamline login to applications after a successful system login. For more information, see Chapter 17, Using PAM.

Sophisticated authentication and authorization mechanisms are available on Solaris systems. For a discussion of authentication and authorization mechanisms at the network level, see Authentication and Authorization for Remote Access.

Managing Password Information

When users log in to a system, they must supply both a user name and a password. Although logins are publicly known, passwords must be kept secret. Passwords should be known only to each user. You should ask your users to choose their passwords carefully. Users should change their passwords often.

Passwords are initially created when you set up a user account. To maintain security on user accounts, you can set up password aging to force users to routinely change their passwords. You can also disable a user account by locking the password. For detailed information about administering passwords, see Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration and the passwd(1) man page.

Local Passwords

If your network uses local files to authenticate users, the password information is kept in the system's /etc/passwd and /etc/shadow files. The user name and other information are kept in the password file /etc/passwd. The encrypted password itself is kept in a separate shadow file, /etc/shadow. This security measure prevents a user from gaining access to the encrypted passwords. While the /etc/passwd file is available to anyone who can log in to a system, only superuser or an equivalent role can read the /etc/shadow file. You can use the passwd command to change a user's password on a local system.

NIS and NIS+ Passwords

If your network uses NIS to authenticate users, password information is kept in the NIS password map. NIS does not support password aging. You can use the command passwd -r nis to change a user's password that is stored in an NIS password map.

If your network uses NIS+ to authenticate users, password information is kept in the NIS+ database. Information in the NIS+ database can be protected by restricting access to authorized users only. You can use the passwd -r nisplus command to change a user's password that is stored in an NIS+ database.

LDAP Passwords

The Solaris LDAP naming service stores password information and shadow information in the ou=people container of the LDAP directory tree. On the Solaris LDAP naming service client, you can use the passwd -r ldap command to change a user's password. The LDAP naming service stores the password in the LDAP repository.

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).

Password Encryption

Strong password encryption provides an early barrier against attack. Solaris software provides four password encryption algorithms. The two MD5 algorithms and the Blowfish algorithm provide more robust password encryption than the UNIX algorithm.

Password Algorithm Identifiers

You specify the algorithms configuration for your site in the /etc/security/policy.conf file. In the policy.conf file, the algorithms are named by their identifier, as shown in the following table.

Algorithms Configuration in the policy.conf File

The following shows the default algorithms configuration in the policy.conf file:

#
…
# crypt(3c) Algorithms Configuration
#
# CRYPT_ALGORITHMS_ALLOW specifies the algorithms that are allowed to
# be used for new passwords.  This is enforced only in crypt_gensalt(3c).
#
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,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.

For more information on configuring the algorithm choices, see the policy.conf(4) man page. To specify password encryption algorithms, see Changing the Password Algorithm (Task Map).

Special System Logins

Two common ways to access a system are by using a conventional user login, or by using the root login. In addition, a number of special system logins enable a user to run administrative commands without using the root account. As system administrator, you assign passwords to these login accounts.

The following table lists some system login accounts and their uses. The system logins perform special functions. Each login has its own group identification number (GID). Each login should have its own password, which should be divulged on a need-to-know basis.

Remote Logins

Remote logins offer a tempting avenue for intruders. The Solaris OS provides several commands to monitor, limit, and disable remote logins. For procedures, see Securing Logins and Passwords (Task Map).

By default, remote logins cannot gain control or read certain system devices, such as the system mouse, keyboard, frame buffer, or audio device. For more information, see the logindevperm(4) man page.

Dial-Up Logins

When a computer can be accessed through a modem or a dial-up port, you can add an extra layer of security. You can require a dial-up password for users who access a system through a modem or dial-up port. The dial-up password is an additional password that a user must supply before being granted access to the system.

Only superuser or a role of equivalent capabilities can create or change a dial-up password. To ensure the integrity of the system, the password should be changed about once a month. The most effective use of this feature is to require a dial-up password to gain access to a gateway system. To set up dial-up passwords, see How to Create a Dial-Up Password.

Two files are involved in creating a dial-up password, /etc/dialups and /etc/d_passwd. The dialups file contains a list of ports that require a dial-up password. The d_passwd file contains a list of shell programs that require an encrypted password as the additional dial-up password. The information in these two files is processed as follows:

• If the user's login shell in /etc/passwd matches an entry in /etc/d_passwd, the user must supply a dial-up password.

• If the user's login shell in /etc/passwd is not found in /etc/d_passwd, the user must supply the default password. The default password is the entry for /usr/bin/sh.

• If the login shell field in /etc/passwd is empty, the user must supply the default password. The default password is the entry for /usr/bin/sh.

• If /etc/d_passwd has no entry for /usr/bin/sh, then those users whose login shell field in /etc/passwd is empty or does not match any entry in /etc/d_passwd are not prompted for a dial-up password.

• Dial-up logins are disabled if /etc/d_passwd has the /usr/bin/sh:*: entry only.

Controlling Access to Devices

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.

Device Policy (Overview)

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:

• Configuring Device Policy (Task Map)

• Device Policy Commands

• Privileges and Devices

Device Allocation (Overview)

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:

• Managing Device Allocation (Task Map)

• Device Allocation

• Device Allocation Commands

Controlling Access to Machine Resources

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.

Limiting and Monitoring Superuser

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).

Configuring Role-Based Access Control to Replace Superuser

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).

Preventing Unintentional Misuse of Machine Resources

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.

Setting the PATH Variable

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.

Assigning a Restricted Shell to Users

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 user cannot redirect output with > or >>.

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.

Restricting Access to Data in Files

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.

Restricting setuid Executable Files

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).

Using the Automated Security Enhancement Tool

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).

Using the Sun Security Toolkit

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.

Using the netservices limited Configuration

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.

Using Solaris Resource Management Features

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.

Using 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.

Monitoring Use of Machine Resources

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).

Monitoring File Integrity

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).

Controlling Access to Files

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).

Protecting Files With Encryption

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).

Using Access Control Lists

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.

Sharing Files Across Machines

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.

Restricting root Access to Shared Files

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.

Controlling Network Access

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 Mechanisms

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.

Figure 2–1 Security Restrictions for Remote Operations

Authentication and Authorization for Remote Access

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.

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”

Firewall Systems

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.

Encryption and Firewall Systems

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.

Reporting Security Problems

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.

Chapter 3 Controlling Access to Systems (Tasks)

This chapter describes the procedures for controlling who can access Solaris systems. The following is a list of the information in this chapter.

• Controlling System Access (Task Map)

• Securing Logins and Passwords (Task Map)

• Changing the Password Algorithm (Task Map)

• Monitoring and Restricting Superuser (Task Map)

• SPARC: Controlling Access to System Hardware (Task Map)

For overview information about system security, see Chapter 2, Managing Machine Security (Overview).

Controlling System Access (Task Map)

A computer is as secure as its weakest point of entry. The following task map shows the areas that you should monitor and secure.

Securing Logins and Passwords (Task Map)

The following task map points to procedures that monitor user logins and that disable user logins.

Securing Logins and Passwords

You can limit remote logins and require users to have passwords. You can also monitor failed access attempts and disable logins temporarily.

How to Display a User's Login Status

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.

2. Display a user's login status by using the logins command.

   # logins -x -l username

   -x

   Displays an extended set of login status information.

   -l username

   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.

Example 3–1 Displaying a User's Login Status

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

rimmer

Identifies the user's login name.

500

Identifies the user ID (UID).

staff

Identifies the user's primary group.

10

Identifies the group ID (GID).

Annalee J. Rimmer

Identifies the comment.

/export/home/rimmer

Identifies the user's home directory.

/bin/sh

Identifies the login shell.

PS 010170 10 7 -1

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

How to Display Users Without Passwords

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.

2. 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.

Example 3–2 Displaying Users Without Passwords

In the following example, the user pmorph does not have a password.

# logins -p
pmorph          501     other           1       Polly Morph
# 

How to Temporarily Disable User Logins

Temporarily disable user logins during system shutdown or routine maintenance. Superuser logins are not affected. For more information, see the nologin(4) man page.

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.

2. Create the /etc/nologin file in a text editor.

   # vi /etc/nologin

3. Include a message about system availability.

4. Close and save the file.

Example 3–3 Disabling User Logins

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.

How to Monitor Failed Login Attempts

This procedure captures failed login attempts from terminal windows. This procedure does not capture failed logins from a CDE or GNOME login attempt.

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.

2. Create the loginlog file in the /var/adm directory.

   # touch /var/adm/loginlog

3. Set read-and-write permissions for root user on the loginlog file.

   # chmod 600 /var/adm/loginlog

4. Change group membership to sys on the loginlog file.

   # chgrp sys /var/adm/loginlog

5. 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.

How to Monitor All Failed Login Attempts

This procedure captures in a syslog file all failed login attempts.

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.

2. 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 #

3. Create a file with the correct permissions to hold the logging information.

   1. Create the authlog file in the /var/adm directory.

      # touch /var/adm/authlog

   2. Set read-and-write permissions for root user on the authlog file.

      # chmod 600 /var/adm/authlog

   3. Change group membership to sys on the authlog file.

      # chgrp sys /var/adm/authlog

4. Edit the syslog.conf file to log failed password attempts.

   The failures should be sent to the authlog file.

   1. Type the following entry into the syslog.conf file.

      Fields on the same line in syslog.conf are separated by tabs.

      auth.notice <Press Tab> /var/adm/authlog

   2. Refresh the configuration information for the syslog daemon.

      # svcadm refresh system/system-log

5. 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 #

6. Monitor the /var/adm/authlog file on a regular basis.

Example 3–4 Logging Access Attempts After Three Login Failures

Follow the preceding procedure, except set the value of SYSLOG_FAILED_LOGINS to 3 in the /etc/default/login file.

Example 3–5 Closing Connection After Three Login Failures

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.

How to Create a Dial-Up Password

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.

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.

2. 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

3. 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.

4. Set ownership to root on the two files.

   # chown root /etc/dialups /etc/d_passwd

5. Set group ownership to root on the two files.

   # chgrp root /etc/dialups /etc/d_passwd

6. Set read-and-write permissions for root on the two files.

   # chmod 600 /etc/dialups /etc/d_passwd

7. Create the encrypted passwords.

   1. Create a temporary user.

      # useradd username

   2. 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

   3. Capture the encrypted password.

      # grep username /etc/shadow > username.temp

   4. 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:

   5. Delete the temporary user.

      # userdel username

8. 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.

9. Inform your dial-up users of the password.

   You should ensure that your means of informing the users cannot be tampered with.

How to Temporarily Disable Dial-Up Logins

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.

2. Put the following single-line entry into the /etc/d_passwd file:

   /usr/bin/sh:*:

Changing the Password Algorithm (Task Map)

The following task map points to procedures to administer password algorithms.

Changing the Default Algorithm for Password Encryption

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.

How to Specify an Algorithm for Password Encryption

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.

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.

2. 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.

Example 3–6 Using the Blowfish Algorithm for Password Encryption

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.

How to Specify a New Password Algorithm for an NIS Domain

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.

1. Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS client.

2. Copy the modified /etc/security/policy.conf file to every client machine in the NIS domain.

3. To minimize confusion, copy the modified /etc/security/policy.conf file to the NIS root server and to the slave servers.

How to Specify a New Password Algorithm for an NIS+ Domain

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.

1. Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS+ master.

2. To minimize confusion, copy the NIS+ master's /etc/security/policy.conf file to every host in the NIS+ domain.

How to Specify a New Password Algorithm for an LDAP 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.

1. Specify a password encryption algorithm in the /etc/security/policy.conf file on the LDAP client.

2. Copy the modified policy.conf file to every client machine in the LDAP domain.

3. 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.

   ---

   Note –

   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).

   ---

How to Install a Password Encryption Module From a Third Party

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.

1. 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.

2. 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

3. 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.

Monitoring and Restricting Superuser (Task Map)

The following task map describes how to monitor and restrict the root user login.

Monitoring and Restricting Superuser

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).

How to Monitor Who Is Using the su Command

The sulog file lists every use of the su command, not only the su attempts that are used to switch from user to superuser.

1. 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

Troubleshooting

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.

How to Restrict and Monitor Superuser Logins

This method immediately detects superuser attempts to access the local system.

1. 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.

2. 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.

3. Monitor attempts to become superuser.

   By default, attempts to become superuser are printed to the console by the SYSLOG utility.

   1. Open a terminal console on your desktop.

   2. In another window, use the su command to become superuser.

      % su - Password: <Type root password> #

      A message is printed on the terminal console.

      Sep 7 13:22:57 mach1 su: 'su root' succeeded for jdoe on /dev/pts/6

Example 3–7 Logging Superuser Access Attempts

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

Troubleshooting

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.

SPARC: Controlling Access to System Hardware (Task Map)

The following task map describes how to protect the PROM from unwanted access.

Controlling Access to System Hardware

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.

How to Require a Password for Hardware Access

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.

1. 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).

2. 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.

3. (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.

   ---

   Caution –

   Do not forget the PROM password. The hardware is unusable without this password.

   ---

How to Disable a System's Abort Sequence

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.

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.

2. 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

3. Update the keyboard defaults.

   # kbd -i

Chapter 4 Controlling Access to Devices (Tasks)

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.

• Configuring Devices (Task Map)

• Configuring Device Policy (Task Map)

• Managing Device Allocation (Task Map)

• Allocating Devices (Task Map)

• Device Protection (Reference)

For overview information about device protection, see Controlling Access to Devices.

Configuring Devices (Task Map)

The following task map points to tasks for managing access to devices.

Configuring Device Policy (Task Map)

The following task map points to device configuration procedures that are related to device policy.

Configuring Device Policy

Device policy restricts or prevents access to devices that are integral to the system. The policy is enforced in the kernel.

How to View Device Policy

1. 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 …

Example 4–1 Viewing the Device Policy for a Specific Device

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

How to Change the Device Policy on an Existing Device

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.

2. Add policy to a device.

   # update_drv -a -p policy device-driver

   -a

   Specifies a policy for device-driver.

   -p policy

   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.

   device-driver

   Is the device driver.

   For more information, see the update_drv(1M) man page.

Example 4–2 Adding Policy to an Existing Device

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

Example 4–3 Removing Policy From a Device

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

How to Audit Changes in Device Policy

By default, the as audit class includes the AUE_MODDEVPLCY audit event.

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.

2. 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.

How to Retrieve IP MIB-II Information From a /dev/* Device

Applications that retrieve Solaris IP MIB-II information should open /dev/arp, not /dev/ip.

1. 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.

2. 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.

Managing Device Allocation (Task Map)

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).

Managing Device Allocation

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.

How to Make a Device Allocatable

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.

1. 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.

2. Enable device allocation.

   # 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.

   ---

   Note –

   The Volume Management daemon (/etc/rc3.d/S81volmgt) is disabled by this command.

   ---

How to Authorize Users to Allocate a Device

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.

2. 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

3. 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.

4. Assign the role to every user who is permitted to allocate a device.

5. 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.

How to View Allocation Information About a Device

Before You Begin

Device allocation must be enabled for this procedure to succeed. To enable device allocation, see How to Make a Device Allocatable.

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.

2. 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.

Troubleshooting

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.

Forcibly Allocating a Device

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.

Before You Begin

The user or role must have the solaris.device.revoke authorization.

1. Determine if you have the appropriate authorizations in your role.

   $ auths solaris.device.allocate solaris.device.revoke

2. 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

Forcibly Deallocating a Device

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.

Before You Begin

The user or role must have the solaris.device.revoke authorization.

1. Determine if you have the appropriate authorizations in your role.

   $ auths solaris.device.allocate solaris.device.revoke

2. 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

How to Change Which Devices Can Be Allocated

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.

2. 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.

Example 4–4 Permitting Any User to Allocate a 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
…

Example 4–5 Preventing Some Peripheral Devices From Being Used

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
…

Example 4–6 Preventing All Peripheral Devices From Being Used

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
…

How to Audit Device Allocation

By default, the device allocation commands are in the other audit class.

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.

2. 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.

Allocating Devices (Task Map)

The following task map points to procedures that show users how to allocate devices.

Allocating Devices

Device allocation reserves the use of a device to one user at a time. Devices that require a mount point must be mounted.

How to Allocate a Device

Before You Begin

Device allocation must be enabled, as described in How to Make a Device Allocatable. If authorization is required, the user must have the authorization.

1. Allocate the device.

   Specify the device by device name.

   % allocate device-name

2. Verify that the device is allocated.

   Run the identical command.

   % allocate device-name allocate. Device already allocated.

Example 4–7 Allocating a Microphone

In this example, the user jdoe allocates a microphone, audio.

% whoami
jdoe
% allocate audio

Example 4–8 Allocating a Printer

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.

Example 4–9 Allocating a Tape Drive

In this example, the user jdoe allocates a tape drive, st0.

% whoami
jdoe
% allocate st0

Troubleshooting

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.

How to Mount an Allocated Device

Before You Begin

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.

1. Assume a role that can allocate and mount a device.

   % su - role-name Password: <Type role-name password> $

2. 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

3. List the allocatable devices.

   $ list_devices -l List of allocatable devices

4. Allocate the device.

   Specify the device by device name.

   $ allocate device-name

5. Mount the device.

   $ mount -o ro -F filesystem-type device-path mount-point

   where

   -o ro

   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.

   -F filesystem-type

   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.

   device-path

   Indicates the path to the device. The output of the list_devices -l command includes the device-path.

   mount-point

   Indicates the mount point that you created in Step 2.

Example 4–10 Allocating a Diskette Drive

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

Example 4–11 Allocating a CD-ROM Drive

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

Troubleshooting

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.

How to Deallocate a Device

Deallocation enables other users to allocate and use the device when you are finished.

Before You Begin

You must have allocated the device.

1. If the device is mounted, unmount the device.

   $ cd $HOME $ umount mount-point

2. Deallocate the device.

   $ deallocate device-name

Example 4–12 Deallocating a Microphone

In this example, the user jdoe deallocates the microphone, audio.

% whoami
jdoe
% deallocate audio

Example 4–13 Deallocating a CD-ROM Drive

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.

Device Protection (Reference)

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 Policy Commands

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.

Device Allocation

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.

Components of Device Allocation

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.

Device Allocation Commands

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.

Authorizations for the 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.

Allocate Error State

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 File

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

Example 4–14 Sample device_maps Entry

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:

device-name

Specifies the name of the device. For a list of current device names, see How to View Allocation Information About a Device.

device-type

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.

device-list

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.

device_allocate File

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:

device-name

Specifies the name of the device. For a list of current device names, see How to View Allocation Information About a Device.

device-type

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.

reserved

Sun reserves the two fields that are marked reserved for future use.

auths

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.

device-exec

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-Clean Scripts

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.

Device-Clean Script for Tapes

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.

Device-Clean Scripts for Diskettes and CD-ROM Drives

The following device-clean scripts are provided for diskettes and CD-ROM drives:

• fd_clean script – Is a device-clean script for diskettes.

• sr_clean script – Is a device-clean script for 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.

Device-Clean Script for Audio

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.

Writing New Device-Clean Scripts

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:

-I

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.

-i

Similar to the -I option, except that output is suppressed.

-f

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.

-S

Is for standard cleanup. The option is interactive and assumes that the user is available to respond to prompts.

Chapter 5 Using the Basic Audit Reporting Tool (Tasks)

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:

• Using BART (Task Map)

• Basic Audit Reporting Tool (Overview)

• Using BART (Tasks)

• BART Manifest, Rules File, and Reporting (Reference)

Basic Audit Reporting Tool (Overview)

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 Features

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 Components

BART has two main components and one optional component:

• BART Manifest

• BART Report

• BART Rules File

BART Manifest

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.

BART Report

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.

BART Rules File

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.

Using BART (Task Map)

Using BART (Tasks)

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).

BART Security Considerations

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.

How to Create a Manifest

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.

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.

2. After installing the Solaris software, create a control manifest and redirect the output to a file.

   # bart create options > control-manifest

   -R

   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.

   -I

   Accepts a list of individual files to be cataloged, either on the command line or read from standard input.

   -r

   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.

   -n

   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.

3. Examine the contents of the manifest.

4. 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.

Example 5–1 Creating a Manifest That Lists Information About Every File on a System

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 #.

How to Customize a Manifest

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.

1. Determine which files you want to catalog and monitor.

2. 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.

3. 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

4. Examine the contents of the manifest.

5. Save the manifest for future use.

Example 5–2 Creating a Manifest by Specifying a Subtree

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
.
.
.

Example 5–3 Customizing a Manifest by Specifying a File Name

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

Example 5–4 Customizing a Manifest by Using a Rules File

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.

How to Compare Manifests for the Same System Over Time

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.

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.

2. 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

3. 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

4. Compare the control manifest with the test manifest.

   # bart compare options control-manifest test-manifest > bart-report

   -r

   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.

   -i

   Allows the user to set global IGNORE directives from the command line.

   -p

   Is the programmatic mode that generates standard non-localized output for programmatic parsing.

   control-manifest

   Is the output from the bart create command for the control system.

   test-manifest

   Is the output from the bart create command of the test system.

5. Examine the BART report for oddities.

Example 5–5 Comparing Manifests for the Same System Over Time

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.

How to Compare Manifests From a Different System With the Manifest of a Control System

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.

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.

2. After installing the Solaris software, create a control manifest.

   # bart create options > control-manifest

3. Save the control manifest.

4. 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.

5. Save the test manifest to a central location on the system until you are ready to compare manifests.

6. 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.

7. Compare the control manifest with the test manifest and redirect the output to a file.

   # bart compare control-manifest test1-manifest > test1.report

8. Examine the BART report for oddities.

9. 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.

Example 5–6 Comparing Manifests From Different Systems With the Manifest of a Control 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.

How to Customize a BART Report by Specifying File Attributes

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.

1. Determine which file attributes you want to monitor.

2. 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.

3. After installing the Solaris software, create a control manifest.

4. Create a test manifest when you want to monitor changes.

   Prepare the test manifest identically to the control manifest.

5. 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.

6. Examine the BART report for oddities.

How to Customize a BART Report by Using a Rules File

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.

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.

2. Determine which files and file attributes you want to monitor.

3. Use a text editor to create a rules file with the appropriate directives.

4. After installing the Solaris software, create a control manifest by using the rules file you created.

   # bart create -r rules-file > control-manifest

5. Create a test manifest that is prepared identically to the control manifest.

   # bart create -r rules-file > test-manifest

6. 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

7. Examine the BART report for oddities.

Example 5–7 Customizing a BART Report by Using a Rules File

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.

BART Manifest, Rules File, and Reporting (Reference)

This section includes the following reference information:

• BART Manifest File Format

• BART Rules File Format

• BART Reporting

BART Manifest File Format

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

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

size

File size in bytes.

mode

Octal number that represents the permissions of the file.

acl

ACL attributes for the file. For a file with ACL attributes, this contains the output from acltotext().

uid

Numerical user ID of the owner of this entry.

gid

Numerical group ID of the owner of this entry.

dirmtime

Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for directories.

lnmtime

Last modification time, in seconds, since 00:00:00 UTC, January 1, 1970, for links.

mtime

Last modification time, in seconds, since 00:00:00 UTC January 1, 1970, for files.

contents

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 –.

dest

Destination of a symbolic link.

devnode

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.

BART Rules File Format

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

Example 5–8 Rules File Format

<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.

Rules File Attributes

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.

Quoting Syntax

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.

BART Reporting

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.

BART Output

The following exit values are returned:

0

Success

1

Nonfatal error when processing files, such as permission problems

>1

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

  filename

  Name of the file that differs between the control manifest and the test manifest.

  attribute

  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]*

  filename

  Same as the filename attribute in the default format

  attribute control-val test-val

  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.

Chapter 6 Controlling Access to Files (Tasks)

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.

• Using UNIX Permissions to Protect Files

• Using Access Control Lists to Protect UFS Files

• Preventing Executable Files From Compromising Security

• Protecting Files (Task Map)

• Protecting Files With UNIX Permissions (Task Map)

• Protecting UFS Files With ACLs (Task Map)

• Protecting Against Programs With Security Risk (Task Map)

Using UNIX Permissions to Protect Files

Files can be secured through UNIX file permissions and through ACLs. Files with sticky bits, and files that are executable, require special security measures.

Commands for Viewing and Securing Files

This table describes the commands for monitoring and securing files and directories.

File and Directory Ownership

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:

- (Minus symbol)

Text or program

b

Block special file

c

Character special file

d

Directory

l

Symbolic link

s

Socket

D

Door

P

Named pipe (FIFO)

UNIX File Permissions

The following table lists and describes the permissions that you can give to each class of user for a file or directory.

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.

Special File Permissions (setuid, setgid and Sticky Bit)

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.

setuid Permission

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.

setgid Permission

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.

Sticky Bit

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.

Default umask Value

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.

For more information on setting the umask value, see the umask(1) man page.

File Permission Modes

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.

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.

The who operator permissions designations in the function column specify the symbols that change the permissions on the file or directory.

who

Specifies whose permissions are to be changed.

operator

Specifies the operation to be performed.

permissions

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.

Using Access Control Lists to Protect UFS Files

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

entry-type

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.

uid

Is the user name or user ID (UID).

gid

Is the group name or group ID (GID).

perms

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.

ACL Entries for 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.

ACL Entries for UFS Directories

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.

Commands for Administering UFS ACLs

The following commands administer ACLs on UFS files or directories.

setfacl command

Sets, adds, modifies, and deletes ACL entries. For more information, see the setfacl(1) man page.

getfacl command

Displays ACL entries. For more information, see the getfacl(1) man page.

Preventing Executable Files From Compromising Security

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.

Protecting Files (Task Map)

The following task map points to sets of procedures for protecting files.

Protecting Files With UNIX Permissions (Task Map)

The following task map points to procedures that list file permissions, change file permissions, and protect files with special file permissions.

How to Display File Information

Display information about all the files in a directory by using the ls command.

1. Type the following command to display a long listing of all files in the current directory.

   % ls -la

   -l

   Displays the long format that includes user ownership, group ownership, and file permissions.

   -a

   Displays all files, including hidden files that begin with a dot (.).

Example 6–1 Displaying File Information

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.

How to Change the Owner of a File

The file owner, the Primary Administrator role, or superuser can change any file's ownership.

1. Display the permissions on a file.

   % ls -l example-file -rw-r--r-- 1 janedoe staff 112640 May 24 10:49 example-file

2. 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.

3. Change the owner of the file.

   # chown stacey example-file

4. 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

Example 6–2 Enabling Users to Change the Ownership of Files That Others Own

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.

How to Change Group Ownership of a File

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.

2. 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.

3. 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.

How to Change File Permissions in Symbolic Mode

1. 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.

2. Change permissions in symbolic mode.

   % chmod who operator permissions filename

   who

   Specifies whose permissions are to be changed.

   operator

   Specifies the operation to be performed.

   permissions

   Specifies what permissions are to be changed. For the list of valid symbols, see Table 6–5.

   filename

   Specifies the file or directory.

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example 6–3 Changing Permissions in Symbolic Mode

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

How to Change File Permissions in Absolute Mode

1. 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.

2. Change permissions in absolute mode.

   % chmod nnn filename

   nnn

   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.

   filename

   Specifies the file or directory.

   ---

   Note –

   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.

   ---

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example 6–4 Changing Permissions in Absolute Mode

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

How to Change Special File Permissions in Absolute Mode

1. 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.

2. Change special permissions in absolute mode.

   % chmod nnnn filename

   nnnn

   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.

   filename

   Specifies the file or directory.

   ---

   Note –

   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.

   ---

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example 6–5 Setting Special File Permissions in Absolute Mode

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

Protecting UFS Files With ACLs (Task Map)

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.

How to Check if a File Has an ACL

1. Check if a file has an ACL.

   % 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.

   ---

   Note –

   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.

   ---

Example 6–6 Checking if a File Has an ACL

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

How to Add ACL Entries to a File

1. 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 ...

   -s

   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.

   user::perms

   Specifies the file owner permissions.

   group::perms

   Specifies the group ownership permissions.

   other:perms

   Specifies the permissions for users other than the file owner or members of the group.

   mask:perms

   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.

   acl-entry-list

   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.

   filename ...

   Specifies one or more files or directories on which to set the ACL. Multiple filenames are separated by spaces.

   ---

   Caution –

   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.

2. 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.

Example 6–7 Setting an ACL on a File

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:---

How to Copy an ACL

1. Copy a file's ACL to another file by redirecting the getfacl output.

   % getfacl filename1 | setfacl -f - filename2

   filename1

   Specifies the file from which to copy the ACL.

   filename2

   Specifies the file on which to set the copied ACL.

Example 6–8 Copying an ACL

In the following example, the ACL on ch2.sgm is copied to ch3.sgm.

% getfacl ch2.sgm | setfacl -f - ch3.sgm

How to Change ACL Entries on a File

1. Modify ACL entries on a file by using the setfacl command.

   % setfacl -m acl-entry-list filename ...

   -m

   Modifies the existing ACL entry.

   acl-entry-list

   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.

   filename ...

   Specifies one or more files or directories, separated by a space.

2. Verify that the ACL entries were modified on the file.

   % getfacl filename

Example 6–9 Modifying ACL Entries on a File

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

How to Delete ACL Entries From a File

1. Delete ACL entries from a file.

   % setfacl -d acl-entry-list filename ...

   -d

   Deletes the specified ACL entries.

   acl-entry-list

   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.

   filename ...

   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.

2. Verify that the ACL entries were deleted from the file.

   % getfacl filename

Example 6–10 Deleting ACL Entries on a File

In the following example, the user anusha is deleted from the ch4.sgm file.

% setfacl -d user:anusha ch4.sgm

How to Display ACL Entries for a File

1. Display ACL entries for a file by using the getfacl command.

   % getfacl [-a | -d] filename ...

   -a

   Displays the file name, file owner, file group, and ACL entries for the specified file or directory.

   -d

   Displays the file name, file owner, file group, and the default ACL entries, if they exist, for the specified directory.

   filename ...

   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.

Example 6–11 Displaying ACL Entries for a File

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:---

Protecting Against Programs With Security Risk (Task Map)

The following task map points to procedures that find risky executables on the system, and that prevent programs from exploiting an executable stack.

How to Find Files With Special File Permissions

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.

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.

2. Find files with setuid permissions by using the find command.

   # find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename

   find directory

   Checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail.

   -user root

   Displays files owned only by root.

   -perm -4000

   Displays files only with permissions set to 4000.

   -exec ls -ldb

   Displays the output of the find command in ls -ldb format.

   >/tmp/filename

   Is the file that contains the results of the find command.

3. Display the results in /tmp/filename.

   # more /tmp/filename

   For background information on setuid permissions, see setuid Permission.