Securing Sun Linux Systems: Part I, Local Access and File Systems

Like this article? We recommend

Securing Systems with the Solaris Toolkit

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Securing Systems with the Solaris Toolkit

Learn More Buy

Managing Accounts

Managing user and system accounts is an important aspect of Sun Linux security. Some system accounts might need to be deleted or modified. The time-based command execution system tools cron and at might need to be configured to restrict user access.

This section contains the following topics:

• "Delete and Modify System Accounts"
• "Restrict at, cron, and batch Command Access"
• "Limit Root Access"
• "Use the Pluggable Authentication Module (PAM)"

Delete and Modify System Accounts

A default Sun Linux installation contains several accounts that either need to be deleted or modified to strengthen security. Some accounts are not necessary for normal system operation. These accounts include games, gopher, and news and uucp. Some of these accounts exist to support software subsystems that are not used or are for backwards compatibility.

To Delete Accounts

• To delete accounts in /etc/passwd and /etc/shadow entries, use the userdel command, similar to the following example:

  # /usr/sbin/userdel games

  This example removes the /etc/passwd and /etc/shadow entries for user games.

  Except for the root account, modify any remaining system accounts for added security by locking them, setting account expiration, or setting their login shells to a restricted value.

To Lock Accounts

• To lock unused accounts that are not locked by default, use the passwd -1 option. For example, if the uucp account is not used, then lock it using the following command.

  # passwd -l <username>

  The password of the account is changed to a string that can never be a valid encrypted password.

To Expire an Account

• To schedule a user account to expire, use the following command:

  # /usr/sbin/usermod -e YYYY-MM-DD <username>

An expired account has similar characteristics to those of an account where the password is locked. The account can still be accessed by root via superuser, daemons can be started, and files and directories can be owned by the account. As with locked accounts, expired accounts cannot be used to login to a system or to access any of the services where authentication is required, such as Telnet, FTP, or IMAP.

To disable interactive access to a user account, use the following command.

# usermod -s /bin/false <username>

An account with a disabled shell (one that is not listed in /etc/shells and does not permit access to the system) only impacts applications that check for valid shells, such as Telnet, FTP, and Secure Shell. This method does not impact other applications such as IMAP and POP that by default do not check this setting.

A better alternative to using /bin/false as a disabled shell is to use a program that not only prevents access to the system but also logs the attempted access. The following shell script could be used to implement such functionality. This example is based on the file /sbin/noshell program available from the Solaris™ Security Toolkit software. For more information on the Solaris Security Toolkit software, refer to http://www.sun.com/security/jass.

#!/bin/sh
#
trap "" 1 2 3 4 5 6 7 8 9 10 12 15 19
PATH=/bin:/usr/bin
export PATH
HNAME="'uname -n'"
UNAME="'id | awk '{ print $1 }''"
logger -i -p auth.crit "Unauthorized access attempt on ${HNAME} by ${UNAME}"

wait
exit

To change default account parameters used during new account creation (via useradd), change the following values in either the /etc/login.defs or the /etc/default/useradd file.

TABLE 1 describes the parameters in the /etc/login.defs file.

TABLE 1 /etc/login.defs File Parameters

TABLE 2 describes the parameters in the /etc/default/useradd file.

TABLE 2 /etc/default/useradd File Parameters

Restrict at, cron, and batch Command Access

The at, cron, and batch commands execute processes (events) at a specified future time. Access control files are stored in the /etc directory.

• The cron.deny and cron.allow files manage access to the cron command.

• The at.deny and at.allow files manage the access to the at and batch commands.

The allow files are checked first to determine if an account is explicitly allowed to use these facilities.

Attackers can use these commands to implement logic bombs (triggered by a system condition, logic that causes damage to data processing systems) or other programmed attacks that begin in the future. Unless administrators examine every at, batch, and cron event, tracking usage and abuse can be difficult. Therefore, we recommend that you restrict access to the at, batch, and cron commands to prevent attacks and abuse.

By default, Sun Linux includes scheduled cron events for the root account. Do not include the root account in the deny files, because any scheduled jobs will be prevented from running.

Add to the deny files any additional system or software-specific accounts that do not require cron, batch, or at access.

You might want to restrict user access to these commands as well. List individual user accounts in the deny files. To restrict all user account access, create an empty allow file, then add only the accounts that need access.

Limit Root Access

The sudo program implements a form of role based access control (RBAC). It is a commonly used tool for limiting access to privileged commands and accounts. Using sudo has the following benefits:

• sudo is configured by default to ask for a user's password

• Fewer users need to log in as privileged users and know the password

• Access to privileged commands is determined by a policy; users are given access only to the commands they need

• Access to privileged commands can be logged

Common uses for sudo are allowing system operators to make backups and create user accounts without giving operators full root access.

To create a new account, an operator enters:

# sudo useradd newuser

It is very important to ensure that mail to root is checked or forwarded. Unauthorized use of sudo generates an email to the root user and creates an entry in the system log /var/log/messages file.

May 4 18:25:14 scl1 sudo(pam_unix)[28769]: authentication failure; logname=attackerid
uid=0 euid=0 tty=pts/2 ruser= rhost= user=attackerid

To review valid uses of sudo, refer to /var/log/secure. In the following example, the sudo command was used by the user joe to access the /bin/bash command as root.

May 4 18:25:28 scl1 sudo: sudoerid: TTY=pts/2 ; PWD=/home/sudoerid/joe ;
USER=root ; COMMAND=/bin/bash

The sudo command consults the /etc/sudoers configuration file to determine if a command is allowed. This configuration file contains access control lists (ACLs) as in the following example.

<user>  <hostname> = '(' <account> ')' <command> [',' <command>]

A rule of this form allows user logged in to hostname to run command as user account. By including the hostname in the rule, it is possible to share a single /etc/sudoers file between multiple machines. For more information about the format of these ACLs, refer to the sudoers manual page.

Use the visudo command to edit the /etc/sudoers file. This command checks the syntax of edited contents before overwriting /etc/sudoers. If the /etc/sudoers syntax is incorrect, sudo does not work.

To keep the description concise, you can define aliases for sets of users, hostnames, and commands. You can use the alias ALL in any field. In the following example, we allow a group of operators to make backups and restore them.

# provide access to dump and restore for backup operators
User_Alias   OPERATORS = tom, dick, harriet
Cmnd_Alias   BACKUPCMD = /sbin/dump, /sbin/restore

OPERATORS    ALL = (root) BACKUPCMD

Be aware that with a little creativity, any user who can make backups and restore them can gain root access, so this example is not a completely secure setup. In general, we advise that you create scripts or programs that wrap commands executed with privilege to limit the options available to its users. In addition, these scripts can sanitize the execution environment by checking or resetting variables such as a user's path to help ensure sane settings. This way, the use of privileged commands can be better controlled.

You can configure sudo to allow only certain parameters to be passed to privileged commands. Verify that operators cannot pass any arguments to privileged commands that have unintended consequences. The following rule allows operators to change passwords for all users except for root.

# User alias specification
User_Alias   OPERATORS = tom, dick, harriet

# Cmnd alias specification
Cmnd_Alias   PASSWDCMD = /usr/bin/passwd, !/usr/bin/passwd root
# Defaults specification
OPERATORS    ALL = (root) PASSWDCMD

The previous example prevents execution of the sudo passwd root command. However, it does allow execution of the sudo passwd --stdin root command. In this case, you can fix the problem by changing the definition of PASSWDCMD slightly, as in the next example.

The following example allows two classes of users (web masters and operators) to manage a system. Web masters can stop and start a web server. Operators can change forgotten user passwords (except for root passwords), start system backups, and perform web master duties.

# User alias specification
User_Alias   OPERATORS = tom, dick, harriet
User_Alias   WEBMASTERS = josephine, OPERATORS

# Cmnd alias specification
Cmnd_Alias   PASSWDCMD = /usr/bin/passwd [!-]*, !/usr/bin/passwd root
Cmnd_Alias   BACKUPCMD = /usr/sbin/backup_script
Cmnd_Alias   HTTPDCTL = /etc/rc.d/init.d/httpd

# Defaults specification

Defaults    authenticate, timestamp_timeout = 60

# User privilege specification
root  ALL=(ALL) NOPASSWD: ALL

OPERATORS    ALL = (root) PASSWDCMD
OPERATORS    ALL = (root) BACKUPCMD
WEBMASTERS   ALL = (root) HTTPDCTL

Use the Pluggable Authentication Module (PAM)

The Pluggable Authentication Module (PAM) architecture allows administrators to control and replace the methods used for authentication. In concept, while this is similar to the PAM functionality that is available in the Solaris OE, note that there are differences.

For more information on the Solaris OE implementation of PAM, refer to the Sun BluePrints OnLine two-part article titled "Extending Authentication in the Solaris 9 OE Using Pluggable Authentication Modules (PAM)."

• Part I: http://www.sun.com/blueprints/0902/816-7669-10.pdf

• Part II: http://www.sun.com/blueprints/1002/816-7670-10.pdf

Although PAM makes authentication operations more robust, it requires that system authentication information be maintained in more places than just /etc/passwd and /etc/shadow. PAM can be expanded to support Kerberos, LDAP, OPIE, S/Key, RSA SecureID, RADIUS, TACACS+, and others. Understanding how the PAM system functions is essential for maintaining the security of a system.

All primary applications such as login, su, ssh, and sudo are PAM aware. Each application that uses PAM does so through a common API that references the general configuration file /etc/pam.conf or the application-specific file in the directory /etc/pam.d/, if it exists.

Within the PAM configuration file, define methods for authentication. Enter one line per method using the following format.

[service] [type] [control] <module-path> <module-arguments>

TABLE 3 lists the values for entering authentication methods.

TABLE 3 PAM Configuration Values

For additional information on PAM, refer to the Linux PAM site at http://www.kernel.org/pub/linux/libs/pam/, the pam(8) manual pages, and the PAM documentation in /usr/share/doc/pam.

After editing the configuration file, test the changes and make any necessary adjustments.

Disabling Null Passwords

A null password allows users to log onto a system without having to first supply a valid password string. When users have null passwords, they can press the Enter key when prompted for a password and gain access to systems without a password. Obviously, this poses a significant security risk to the system and to the accountability of actions performed by users.

To Disable Null Passwords

• Make a backup of the /etc/pam.d/system-auth file, then modify the original by removing nullok from the line, resulting in the following:

auth sufficient /lib/security/pam_unix.so likeauth

Checking Passwords Against a Dictionary

Sun Linux can be configured to verify that passwords cannot be guessed easily. On Sun Linux, this check is performed by the module /lib/security/pam_cracklib.so. It checks to ensure that passwords are a minimum length and verifies that a password does not occur in a dictionary.

The dictionary used by this module is located in /usr/lib and is in cracklib format. By default, each of the dictionary files is prefixed with the file name cracklib_dict. For more information on cracklib including how to add new words to the dictionary, refer to http://www.crypticide.org/users/alecm/.

This module has a number of parameters, the most useful of which are as follows.

TABLE 4 pam_cracklib Parameters

To Check Passwords

• Add the following parameters to an entry in /etc/pam.d/system-auth, resulting in the following single line:

  password required /lib/security/pam_cracklib.so retry=3 type= minlen=8 difok=3

Preventing Reuse of Old Passwords

The PAM module pam_unix.so can be configured to maintain a list of old passwords for every user, to prohibit the reuse of old passwords. The list /etc/security/opasswd is not maintained as plain text, but should be protected the same as shadow password files. This capability is often referred to as password history.

To Retain a List of Passwords

• To remember the last 15 passwords, add the following line in /etc/pam.d/system-auth file:

  password  sufficient  /lib/security/pam_unix.so use_authtok md5 shadow remember=15

Preventing Password Guessing

The module pam_tally keeps track of unsuccessful login attempts, and disables user accounts (not user IDs) when a preset limit is reached. This capability is often referred to as account lockout.

To Prevent Password Guessing

• Add two entries in the /etc/pam.d/system-auth file:

  auth    required   /lib/security/pam_tally.so onerr=fail no_magic_root
  account   required   /lib/security/pam_tally.so deny=5 no_magic_root reset

  Because the order of the lines in /etc/pam.d/system-auth is important, we list the complete file contents.

  auth    required   /lib/security/pam_env.so
  auth    required   /lib/security/pam_tally.so onerr=fail
    no_magic_root
  auth    sufficient  /lib/security/pam_unix.so likeauth
  auth    required   /lib/security/pam_deny.so
  
  account   required   /lib/security/pam_unix.so
  account   required   /lib/security/pam_tally.so deny=5
    no_magic_root reset
  
  password  required   /lib/security/pam_cracklib.so retry=3
    type= minlen=8 difok=3
  password  sufficient  /lib/security/pam_unix.so use_authtok
    md5 shadow remember=15
  password  required   /lib/security/pam_deny.so
  
  session   required   /lib/security/pam_limits.so
  session   required   /lib/security/pam_unix.so