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
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.
For more information, see Preventing Executable Files From Compromising Security. For procedures, see Protecting Against Programs With Security Risk (Task Map).
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, https://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. Then, the only network service that accepts network requests is
the sshd daemon. All other network services are disabled or handle local requests
only. To enable individual network services, such as ftp, you use the Solaris
Service Management Facility (SMF). For more information, see the netservices(1M) and smf(5) man pages.
Using Solaris Resource Management Features
Solaris software provides sophisticated resource management features. Using these features, you can allocate, schedule,
monitor, and cap resource use by applications in a server consolidation environment. The
resource controls framework enables you to set constraints on system resources that are
consumed by processes. Such constraints help to prevent denial-of-service attacks by a script
that attempts to flood a system's resources.
With Solaris resource management features, you can designate resources for particular projects. You
can also dynamically adjust the resources that are available. For more information, see
Part I, Resource Management, in System Administration Guide: Virtualization Using the Solaris Operating System.
Using Solaris Zones
Solaris zones provide an application execution environment in which processes are isolated
from the rest of the system within a single instance of the Solaris
OS. This isolation prevents processes that are running in one zone from monitoring
or affecting processes that are running in other zones. Even a process running
with superuser capabilities cannot view or affect activity in other zones.
Solaris zones are ideal for environments that place several applications on a single
server. For more information, see Part II, Zones, in System Administration Guide: Virtualization Using the Solaris Operating System.
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).