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. This section
also includes a chapter about scanning files for viruses.

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.

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.

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.

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:

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.

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.

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 Encryption

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

Password Algorithm Identifiers

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

Table 2–1 Password Encryption Algorithms

Identifier

Description

Algorithm Man Page

1

The MD5 algorithm that is compatible with MD5 algorithms on BSD
and Linux systems.

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.

Identifier = Password Algorithm

Explanation

Initial Password

Changed Password

1 = crypt_bsdmd5

Uses same algorithm

The 1 identifier is also the value of CRYPT_DEFAULT. The user's password continues to be encrypted with the crypt_bsdmd5 algorithm.

2a = crypt_bsdbf

Uses same algorithm

The 2a identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password is encrypted with the crypt_bsbdf algorithm.

md5 = crypt_md5

Uses same algorithm

The md5 identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password is encrypted with the crypt_md5 algorithm.

5 = crypt_sha256

Uses same algorithm

The 5 identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password is encrypted with the crypt_sha256 algorithm.

6 = crypt_sha512

Uses same algorithm

The 6 identifier is in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the new password is encrypted with the crypt_sha512 algorithm.

__unix__ = crypt_unix

Uses crypt_bsdmd5 algorithm

The __unix__ identifier is not in the CRYPT_ALGORITHMS_ALLOW list. Therefore, the crypt_unix algorithm cannot
be used. The new password is encrypted with the CRYPT_DEFAULT algorithm.

Special System Logins

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

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

Table 2–2 System Login Accounts and Their
Uses

Login Account

GID

Use

root

0

Has almost no restrictions. Overrides all other logins, protections,
and permissions. The root account has access to the entire
system. The password for the root login should be very
carefully protected. The root account, superuser, owns
most of the Solaris commands.

Is used by remote systems to log in to the system and start file transfers.

Remote Logins

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

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

Dial-Up Logins

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

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

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

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

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

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

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

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

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 10 release, 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.

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. In the Solaris 10 release,
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.

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.

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.

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

Using the Solaris Security Toolkit

the Solaris Security Toolkit provides a flexible
and extensible mechanism to minimize, harden, and secure a Solaris system.
The Solaris 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://wwws.sun.com/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.

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.

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

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.

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.

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.

The remote login commands enable users to log in to a remote system
over the network and use its resources. Some of the remote login commands
are rlogin, rcp, and ftp.
If you are a “trusted host,” authentication is automatic. Otherwise,
you are asked to authenticate yourself.

The Simple Authentication and Security Layer (SASL) is a framework that
provides authentication and optional security services to network protocols.
Plugins enable you to choose an appropriate authentication protocol.

Secure RPC improves the security of network environments by authenticating
users who make requests on remote machines. You can use either the UNIX, DES,
or Kerberos authentication system for Secure RPC.

Secure RPC can also be used to provide additional security in an NFS
environment. An NFS environment with secure RPC is called Secure NFS. Secure
NFS uses Diffie-Hellman authentication for public keys.

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.

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.

Caution –

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:

The Solaris 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://wwws.sun.com/security/jass.

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.

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.

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.

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.

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

Caution –

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.

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.

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:

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.

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

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

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

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.

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

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

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.

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

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

Ensure that the client's /etc/pam.conf file
does not use a pam_ldap module.

Ensure that
a comment sign (#) precedes entries that include pam_ldap.so.1. Also, do not use the new server_policy option
with the pam_authtok_store.so.1 module.

The PAM entries in the client's pam.conf file enable
the password to be encrypted according to the local algorithms configuration.
The PAM entries also enable the password to be authenticated.

When users in the LDAP domain change their passwords, the LDAP client
consults its local algorithms configuration in the /etc/security/policy.conf file. The LDAP client machine encrypts the password. Then, the
client sends the encrypted password, with a {crypt} tag,
to the server. The tag tells the server that the password is already encrypted.
The password is then stored, as is, on the server. For authentication, the
client retrieves the stored password from the server. The client then compares
the stored password with the encrypted version that the client has just generated
from the user's typed password.

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.

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.

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.

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.

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

Open a terminal console on your desktop.

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.

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

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.

Chapter 4 Virus Scanning Service
(Tasks)

About Virus Scanning

Data is protected from viruses by a scanning service, vscan, that uses
various scan engines. A scan engine is a third-party application,
residing on an external host, that examines a file for known viruses. A file
is a candidate for virus scanning if the file system supports the vscan service,
the service has been enabled, and the type of file has not been exempted.
The virus scan is then performed on a file during open and close operations
if the file has not been scanned with the current virus definitions previously
or if the file has been modified since it was last scanned.

The vscan service can be configured to use multiple scan engines. It
is recommended that the vscan service use a minimum of two scan engines. The
requests for virus scans are distributed among all available scan engines. Table 4–1 shows the
scan engines that are supported when configured with their most recent patch.

Table 4–1 Antivirus Scan Engine
Software

Antivirus Software

ICAP Support

Symantec Antivirus Scan Engine 4.3

Is supported

Symantec Antivirus Scan Engine 5.1

Is supported

Computer Associates eTrust AntiVirus 7.1

Computer Associates Integrated Threat Management 8.1

Is not supported [Requires installation of the Sun StorageTek 5000 NAS ICAP Server for
Computer Associates Antivirus Scan Engine. Get the package from the Sun Download Center:.]

Trend Micro Interscan Web Security Suite (IWSS) 2.5

Is supported

McAfee Secure Internet Gateway 4.5

Is supported

About the Vscan Service

The benefit of the real-time scan method is that a file is scanned with
the latest virus definitions before it is used. By using
this approach, viruses can be detected before they compromise data.

The following describes the virus scanning process:

When a user opens a file from the client, the vscan service
determines whether the file needs to be scanned, based on whether the file
has been scanned with the current virus definitions previously and if the
file has been modified since it was last scanned.

If the file needs to be scanned, the file is transferred to
the scan engine. If a connection
to a scan engine fails, the file is sent to another scan engine. If no scan
engine is available, the virus scan fails and access to the file might be
denied.

If the file does not need to be scanned, the client is permitted
to access the file.

The scan engine scans the file using the current virus definitions.

If a virus is detected, the file is marked as quarantined.
A quarantined file cannot be read, executed, or renamed but it can be deleted.
The system log records the name of the quarantined file and the name of the
virus and, if auditing has been enabled, an audit record with the same information
is created.

If the file is not infected, the file is tagged with a scan
stamp and the client is permitted to access the file.

Using the Vscan Service

Scanning files for viruses is available when the following requirements
are met:

At least one scan engine is installed and configured.

The files reside on a file system that supports virus scanning.

Virus scanning is enabled on the file system.

The vscan service is enabled.

The vscan service is configured to scan files of the specified
file type.

The following table points to the tasks you perform to set up the vscan
service.

To add a scan engine to the vscan service with default properties,
type:

#vscanadm add-engine engine_ID

See the manpage for the vscanadm(1M) command for a description of the
command.

How to View Vscan Properties

View the properties of the vscan service, of all scan engines,
or of a specific scan engine.

To view the properties of a particular scan engine, type:

# vscanadm get-engine engineID

To view the properties of all scan engines, type:

# vscanadm get-engine

To view one of the properties of the vscan service, type:

# vscanadm get -p property

where property is one of the parameters described
in the manpage for the vscanadm(1M) command.

For example, if you want to see the maximum size of a file that can
be scanned, type:

# vscanadm get max-size

How to Change Vscan Properties

You can change the properties of a particular scan engine and the general
properties of the vscan service. Many scan engines limit the size of the files
they scan, so the vscan service's max-size property
must be set to a value less than or equal to the scan engine's maximum allowed
size. You then define whether files that are larger than the maximum size,
and therefore not scanned, are accessible.

Use the “VSCAN Management” RBAC profile to obtain
the authorizations needed for managing the vscan service.

Specify that access is denied to any file that is not scanned
due to its size.

# vscanadm set -p max-size-action=deny

See the manpage for the vscanadm(1M) command for a description of the
command.

How to Exclude Files
From Virus Scans

When you enable antivirus protection, you can specify that all files
of specific types are excluded from the virus scan. Because the vscan service
affects the performance of the system, you can conserve system resources by
targeting specific file types for virus scans.

Use the “VSCAN Management” RBAC profile to obtain
the authorizations needed for managing the vscan service.

How to Change the Device Policy on an Existing
Device

Assume a role that includes the Device Security rights profile,
or become superuser.

The Primary Administrator role includes the
Device Security rights profile. You can also assign the Device Security rights
profile to a role that you create. To create the role and assign the role
to a user, see Example 9–3.

Add policy to a device.

# update_drv -a -p policy device-driver

-a

Specifies a policy for device-driver.

-ppolicy

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.

Note that the net_rawaccess privilege is required
for reading and writing to /dev/ip. No privileges are
required for /dev/arp.

Open /dev/arp and push the tcp and udp modules.

No privileges are required. This method
is equivalent to opening /dev/ip and pushing the arp, tcp and udp modules. Because
opening /dev/ip now requires a privilege, the /dev/arp method is preferred.

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.

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.

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.

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

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

Assume a role that includes the Device Security rights profile,
or become superuser.

The Primary Administrator role includes the
Device Security rights profile. You can also assign the Device Security rights
profile to a role that you create. To create the role and assign the role
to a user, see Example 9–3.

Display information about allocatable
devices on your system.

# list_devices device-name

where device-name is one of the following:

audio[n] –
Is a microphone and speaker.

fd[n] –
Is a diskette drive.

sr[n] –
Is a CD-ROM drive.

st[n] –
Is a tape drive.

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.

Determine if you have the appropriate authorizations in your role.

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

Forcibly allocate the device to the user who needs the device.

In this example, the tape drive is forcibly allocated to the user jdoe.

$ allocate -U jdoe

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.

Determine if you have the appropriate authorizations in your role.

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

Forcibly deallocate the device.

In this example, the
printer is forcibly deallocated. The printer is now available for allocation
by another user.

$ deallocate -f /dev/lp/printer-1

How to Change Which Devices Can Be Allocated

Assume a role that includes the Device Security rights profile,
or become superuser.

The Primary Administrator role includes the
Device Security rights profile. You can also assign the Device Security rights
profile to a role that you create. To create the role and assign the role
to a user, see Example 9–3.

Specify if authorization is required, or specify the solaris.device.allocate authorization.

Change
the fifth field in the device entry in the device_allocate file.

Example 5–9 Allocating a Tape Drive

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.

Assume a role that can allocate and mount a device.

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

Create and protect a mount point in the role's
home directory.

You only need to do this step the first time you
need a mount point.

$ mkdir mount-point ; chmod 700 mount-point

List the allocatable devices.

$ list_devices -l
List of allocatable devices

Allocate the device.

Specify the device by device
name.

$ allocate device-name

Mount the device.

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

where

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

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

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.

If the device is mounted, unmount the device.

$ cd $HOME
$ umount mount-point

Deallocate the device.

$ deallocate device-name

Example 5–12 Deallocating a Microphone

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

% whoami
jdoe
% deallocate audio

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

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.

Table 5–1 Device Management Commands

Command

Purpose

Man Page

devfsadm

Administers devices and device drivers on a running system. Also loads
device policy.

The devfsadm command enables the cleanup of dangling /dev links to disk, tape, port, audio, and pseudo devices. Devices
for a named driver can also be reconfigured.

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.

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.

Note –

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.

Table 5–2 Device Allocation Commands

Command

Purpose

Man Page

bsmconv

Creates databases to handle device allocation. Also enables the auditing
service. You must be superuser or in the Primary Administrator role.

Lists the devices that are allocatable or allocated to the specified
user ID. This option allows you to check which devices are allocatable or
allocated to another user. You must have the solaris.device.revoke authorization.

allocate

Reserves an allocatable device for use by one user.

By default, a user must have the solaris.device.allocate authorization to allocate a device. You can modify the device_allocate file to not require user authorization. Then, any user on the
system can request the device to be allocated for use.

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.

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 5–14 Sample device_maps Entry

The following is an example
of an entry in a device_maps file for a diskette drive, fd0:

Lines in the device_maps file can end with a backslash (\) to continue
an entry on the next line. Comments can also be included. A pound sign (#) comments all subsequent text until the next newline that is not
immediately preceded by a backslash. Leading and trailing blanks are allowed
in any field. The fields are defined as follows:

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

An entry in the device_allocate file does not mean that the device is allocatable,
unless the entry specifically states that the device is allocatable. In the
sample device_allocate file, note the asterisk (*)
in the fifth field of the audio device entry. An asterisk in the fifth field
indicates to the system that the device is not allocatable. Therefore, the
device cannot be used. Other values or no value in this field indicates that
the device can be used.

In the device_allocate file,
each device is represented by a one-line entry of the form:

device-name;device-type;reserved;reserved;auths;device-exec

Lines in the device_allocate file can end with a backslash (\) to continue
an entry on the next line. Comments can also be included. A pound sign (#) comments all subsequent text until the next newline that is not
immediately preceded by a backslash. Leading and trailing blanks are allowed
in any field. The fields are defined as follows:

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

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.

Note –

XylogicsTM 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_cleanscript – Is a device-clean script for diskettes.

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

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.

Note –

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

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.

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.

Note –

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.

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.

Note –

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.

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.

Examine the contents of the manifest.

Save the manifest for future use.

Choose a meaningful name for the manifest. For example, use the system
name and date that the manifest was created.

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

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.

Example 6–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

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.

After installing the Solaris software, create a control manifest
of the files that you want to monitor on the system.

# bart create -R /etc > control-manifest

Create a test manifest that is prepared identically to the control
manifest whenever you want monitor changes to the system.

# bart create -R /etc > test-manifest

Compare the control manifest with the test manifest.

# bart compare optionscontrol-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.

Examine the BART report for oddities.

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

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.

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.

Note that a comma separates each attribute you specify in the command-line
syntax.

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.

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

BART Manifest, Rules File, and Reporting (Reference)

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.

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.

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.

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:

filenameattributecontrol-valtest-val [attributecontrol-valtest-val]*

filename

Same as the filename attribute
in the default format

attributecontrol-valtest-val

A description of the file attributes that differ between the
control and test manifests for each file

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

Table 7–2 File and Directory Permissions

Symbol

Permission

Object

Description

r

Read

File

Designated users can open and read the contents of a file.

Directory

Designated users can list files in the directory.

w

Write

File

Designated users can modify the contents of the file or delete the file.

Directory

Designated users can add files or add links in the directory. They can
also remove files or remove links in the directory.

x

Execute

File

Designated users can execute the file, if it is a program or shell script.
They also can run the program with one of the exec(2) system
calls.

Directory

Designated users can open files or execute files in the directory. They
also can make the directory and the directories beneath it current.

-

Denied

File and Directory

Designated users cannot read, write, or execute the file.

These file permissions apply to regular files, and to special files
such as devices, sockets, and named pipes (FIFOs).

For a symbolic link, the permissions that apply are the permissions
of the file that the link points to.

You can protect the files in a directory and its subdirectories by setting
restrictive file permissions on that directory. Note, however, that superuser
has access to all files and directories on the system.

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.

Note –

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

Table 7–3 umask Settings
for Different Security Levels

Level of Security

umask Setting

Permissions Disallowed

Permissive (744)

022

w for group and others

Moderate (740)

027

w for group, rwx for others

Moderate (741)

026

w for group, rw for others

Severe (700)

077

rwx for group and others

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

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.

Table 7–4 Setting File Permissions in Absolute
Mode

Octal Value

File Permissions Set

Permissions Description

0

---

No permissions

1

--x

Execute permission only

2

-w-

Write permission only

3

-wx

Write and execute permissions

4

r--

Read permission only

5

r-x

Read and execute permissions

6

rw-

Read and write permissions

7

rwx

Read, write, and execute permissions

The following
table lists the symbols for setting file permissions in symbolic mode. Symbols
can specify whose permissions are to be set or changed, the operation to be
performed, and the permissions that are being assigned or changed.

Table 7–5 Setting File Permissions in Symbolic
Mode

Symbol

Function

Description

u

who

User (owner)

g

who

Group

o

who

Others

a

who

All

=

operator

Assign

+

operator

Add

-

operator

Remove

r

permissions

Read

w

permissions

Write

x

permissions

Execute

l

permissions

Mandatory locking, setgid bit is on, group execution
bit is off

s

permissions

setuid or setgid bit is on

t

permissions

Sticky bit is on, execution bit for others is on

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

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.

Table 7–6 Setting Special File Permissions
in Absolute Mode

Octal Value

Special File Permissions

1

Sticky bit

2

setgid

4

setuid

Using Access Control Lists to Protect Files

Traditional UNIX file protection provides read, write, and execute permissions
for the three user classes: file owner, file group, and other. An access control
list (ACL) provides better file security by enabling you to do the following:

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. The entries are set through the setfacl command. 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 7–7 and Table 7–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-

Caution –

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 Files

The following table lists the valid ACL entries that you might use when
setting ACLs on files. The first three ACL entries provide the basic UNIX
file protection.

Table 7–7 ACL Entries for Files

ACL Entry

Description

u[ser]::perms

File owner permissions.

g[roup]::perms

File group permissions.

o[ther]:perms

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

m[ask]:perms

The ACL mask. The mask entry indicates the maximum permissions that
are allowed for users (other than the owner) and for groups. The mask is a
quick way to change permissions on all the users and groups.

For example, the mask:r-- mask entry indicates that
users and groups cannot have more than read permissions, even though they
might have write and execute permissions.

u[ser]:uid:perms

Permissions for a specific user. For uid,
you can specify either a user name or a numeric UID.

g[roup]:gid:perms

Permissions for a specific group. For gid,
you can specify either a group name or a numeric GID.

ACL Entries for Directories

In addition to the ACL entries that are described in Table 7–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 7–8 lists the default ACL
entries for directories.

When you set default ACL entries for specific users and groups on a
directory for the first time, you must also set default ACL entries for the
file owner, file group, others, and the ACL mask. These entries are required.
They are the first four default ACL entries in the following table.

Table 7–8 Default ACL Entries for Directories

Default ACL Entry

Description

d[efault]:u[ser]::perms

Default file owner permissions.

d[efault]:g[roup]::perms

Default file group permissions.

d[efault]:o[ther]:perms

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

d[efault]:m[ask]:perms

Default ACL mask.

d[efault]:u[ser]:uid:perms

Default permissions for a specific user. For uid,
you can specify either a user name or a numeric UID.

d[efault]:g[roup]:gid:perms

Default permissions for a specific group. For gid,
you can specify either a group name or a numeric GID.

Commands for Administering ACLs

The following commands administer ACLs on 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 syslogkern 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.

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

How to Change File Permissions in Symbolic
Mode

If you are not the owner of the file or directory, become superuser
or assume an equivalent role.

Only the current owner or superuser
can use the chmod command to change file permissions on
a file or directory.

Change permissions in symbolic mode.

% chmod who operator permissions filename

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

filename

Specifies the file or directory.

Verify that the permissions of the file have changed.

% ls -l filename

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

If you are not the owner of the file or directory, become superuser
or assume an equivalent role.

Only the current owner or superuser
can use the chmod command to change file permissions on
a file or directory.

Change permissions in absolute mode.

% chmod nnnfilename

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

Verify that the permissions of the file have changed.

% ls -l filename

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

How to Change Special File Permissions
in Absolute Mode

If you are not the owner of the file or directory, become superuser
or assume an equivalent role.

Only the current owner or a user
with superuser capabilities can use the chmod command to
change the special permissions on a file or directory.

Change special permissions in absolute
mode.

% chmod nnnnfilename

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

Verify that the permissions of the file have changed.

% ls -l filename

Example 7–5 Setting Special File Permissions in Absolute Mode

In the following example, the setuid permission is
set on the dbprog file.

How to Add ACL Entries to a File

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

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

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.

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

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

Verify that the ACL entries were deleted from the file.

% getfacl filename

Example 7–10 Deleting ACL Entries on a File

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

How to Display ACL Entries for a File

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

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.

Example 7–12 Finding Files With setuid Permissions

The output from the following example shows that a user named rar has
made a personal copy of /usr/bin/sh, and has set the
permissions as setuid to root. As a
result, the /usr/rar/bin/sh program runs with root permissions.

This output was saved for future reference by moving the file out of
the /tmp directory.