|Previous||Table of Contents||Next|
This part introduces system security in three chapters. Chapter 18 introduces the basic concepts of system security, including file, system, and network security. Chapter 19 describes how to use authentication services. It provides an overview of secure RPC and explains how to use pluggable authentication modules (PAM). Chapter 20 describes how to set up and use Automated Security Enhancement Tool (ASET).
Refer to these three chapters if you want to familiarize yourself with the basics of system security and if you want to use authentication services and ASET security.
MANAGING SYSTEM SECURITY IS AN IMPORTANT PART OF SYSTEM ADMINISTRATION. THIS chapter provides information about managing system security at the file, system, and network level.
At the file level, the Solaris 2.x operating system provides some standard security features that you can use to protect files, directories, and devices. At the system and network levels, the security issues are similar. In the workplace, a number of systems connected to a server can be viewed as a large, multifaceted system. When you are responsible for the security of this larger system or network, it is important for you to defend the network from outsiders trying to gain access. In addition, it is important to ensure the integrity of the data on the systems within the network.
The Solaris 2.6 release provides two new features to enhance security:
PAM enables you to plug in new authentication technologies without changing the login, ftp, or telnet commands. You can also use PAM to integrate UNIX login with other security mechanisms, such as data encryption standard (DECS) or Kerberos. You can also plug in mechanisms for account, session, and password management using this framework. For more information, see Chapter 19, Using Authentication Services.
A number of security bugs are related to default executable stacks when permissions are set to read, write, and execute. Although the SPARC and Intel application binary interface (ABI) mandates that stacks have execute permissions, most programs can function correctly without using executable stacks.
The Solaris 2.6 release provides a noexec_user_stack variable, which enables you to specify whether stack mappings are executable or not. By default, the value for the variable is zero, which provides ABI-compliant behavior. If the variable is set to non-zero, the system marks the stack of every process in the system as readable and writable but not executable.
Use the following steps to disable programs from using executable stacks:
When the variable is set to a non-zero value, programs that execute code on their stack are sent a SIGSEGV signal, which usually terminates the program with a core dump. Such programs also generate a warning message, which includes the name of the program, the PID, and the UID of the user who ran the program, as shown in the following example:
a.out attempt to execute code on stack by uid 555
The message is logged by the syslogd(1M) daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf(4) file, which means that the message is sent to both the console and to the /var/adm/messages file.
When you have set the noexec_user_stack variable, you can monitor these messages to observe potential security problems. You can also monitor the messages to identify valid programs that depend on executable stacks and have been prevented from correct operation.
You can explicitly mark program stacks as executable by using the mprotect(2) function. See the mprotect(2) manual page for more information.
NOTE: Because of hardware limitations, executable stack problems can be caught and reported only on sun4m, sun4d, and sun4u platforms.
If you do not want to log executable stack messages, you can set the noexec_user_stack_log variable to zero in the /etc/system file. Note that even if you disable executable stack message logging, the SIGSEGV signal may continue to dump core for the executing program.
Use the following steps to disable executable stack message logging:
The first line of security defense is to control access to systems. You can control and monitor system access in the following ways:
To control access to systems, your company must maintain the physical security of the computer environment. For instance, if a user logs on to a system and leaves it unattended, anyone who can use that system can gain access to the operating system and the network. Be aware of your users' surroundings and educate them to physically protect the computers from unauthorized access.
Use password and login control to restrict unauthorized logins to a system or to the network. All accounts on a system should have a password. A single account without a password makes your entire network accessible to anyone who knows or can guess a username.
Solaris 2.x system software restricts control of certain system devices to the user login account. Only a process running as superuser or console user can access a system mouse, keyboard, frame buffer, or audio device unless /etc/logindevperm is edited. See the logindevperm(4) manual page for more information.
Use UNIX directory and file permissions to control access to the data on your users' systems. You may want to enable some people to read certain files and grant other people permission to change or delete certain files. You may have data that you do not want anyone else to see. See File Security on page 394 for information on how to set file permissions.
|Previous||Table of Contents||Next|