Go to main content

Securing Systems and Attached Devices in Oracle® Solaris 11.3

Exit Print View

Updated: April 2019
 
 

Controlling Access to System Resources

Some system resources are protected by default. Additionally, 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 systems to minimize improper use of resources.

Using the Secure by Default Configuration

By default, when Oracle Solaris is installed, a large set of network services are disabled. This configuration is called "Secure by Default" (SBD). 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 Service Management Facility (SMF) feature of Oracle Solaris. For more information, see the netservices(1M) and smf(5) man pages.

Preventing Intentional Misuse of System Resources

Malware can target memory, process heaps, buffers, and other vulnerable areas in the kernel. Oracle Solaris provides a Security Extensions Framework to protect applications from malware. Security extensions provide system-level security defenses, although applications can explicitly opt in and opt out of each particular defense.

For more information, see Protecting Against Malware With Security Extensions and the sxadm(1M) man page.

Limiting and Monitoring Superuser Access

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, users must log in with their 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 root Access.

Configuring Role-Based Access Control to Replace Superuser

Role-based access control (RBAC), a feature of Oracle Solaris, distributes the capabilities of superuser to administrative roles. Roles get these capabilities through bundles called rights profiles. Regular users can also be assigned rights profiles.

Superuser, the root user, has access to every resource in the system. With RBAC, you can replace many of root's responsibilities 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. Although you might not modify the root account, you can leave the account as a role, then not assign the role. This strategy effectively removes root access to the system.

Each role requires that a known user log in with her or his user name and password. After logging in, the user then assumes the role with a specific role password. If you assign rights profiles directly to a user, the user must open a profile shell to gain administrative powers. For more information about RBAC, see User Rights Management in Securing Users and Processes in Oracle Solaris 11.3.

Preventing Unintentional Misuse of System 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

Take care to correctly set the PATH variable. Otherwise, you can accidentally run a program that was introduced by someone else that creates a security hazard. The intruding program can corrupt your data or harm your system. This kind of program 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 your initialization files, such as .bashrc and /etc/profile. 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 the root account 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 a standard shell in the following ways:

  • User access 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 commands only 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 intended only 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 Oracle Solaris 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 1, Controlling Access to Files in Securing Files and Verifying File Integrity in Oracle Solaris 11.3 discusses how to set file permissions.

Restricting setuid Executable Files

Executable files can be security risks. A few executable programs still have to be run as root 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 Oracle Solaris provides 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 must restrict their use. Secure administration requires few setuid programs.

For more information, see Protecting Executable Files From Compromising Security in Securing Files and Verifying File Integrity in Oracle Solaris 11.3. For procedures, see Protecting Against Programs With Security Risk in Securing Files and Verifying File Integrity in Oracle Solaris 11.3.

Using Resource Management Features

Oracle 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 these resource management features, you can designate resources for particular projects. You can also dynamically adjust the resources that are available. For more information, see Administering Resource Management in Oracle Solaris 11.3.

Using Oracle Solaris Zones

Oracle Solaris zones provide an application execution environment in which processes are isolated from the rest of the system within a single instance of the Oracle 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.

Oracle Solaris zones are ideal for environments that place several applications on a single server. For more information, see Introduction to Oracle Solaris Zones.

Auditing System Use

    As a system administrator, you need to monitor system activity. You need to be aware of all aspects of your computer systems, 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 about the audit service, see Chapter 1, About Auditing in Oracle Solaris in Managing Auditing in Oracle Solaris 11.3.

Monitoring Compliance

As a system administrator, you need to monitor that your systems comply with site security requirements. The compliance command can verify that one or more systems comply with the security profile that is set for those systems. For more information, see Oracle Solaris 11.3 Security Compliance Guide. Compliance offers a more complete check than BART, as described in Monitoring File Integrity.