Keeping a machine's information secure is an important system administration responsibility. This chapter provides overview information about managing machine security.The following is a list of the overview information in this chapter.Enhancements to Machine Security in the Solaris 10 Release Controlling Access to a Computer System Controlling Access to Devices Controlling Access to Machine Resources Controlling Access to Files Controlling Network Access Reporting Security Problems new featuressystem security enhancements Since the Solaris 9 release, the following features have been introduced to enhance system security:Strong password encryption is available and configurable. For more information, see Password Encryption. Device policy is enforced with privileges. For more information, see Device Policy (Overview).For device allocation, the /etc/security/dev directory might not be supported in future releases of the Solaris OS. The Basic Audit Reporting Tool (BART) can monitor the authenticity of the files on your system. For more information, see Chapter 6, Using the Basic Audit Reporting Tool (Tasks). Files can be protected with strong encryption. For more information, see Protecting Files With Encryption. Privileges enforce process rights at the kernel level. For more information, see Privileges (Overview). The Solaris Cryptographic Framework centralizes cryptographic services for providers and for consumers. For more information, see Chapter 13, Solaris Cryptographic Framework (Overview). The PAM framework provides functionality for many programs, such as Solaris Secure Shell. For more information, see Changes to PAM for the Solaris 10 Release. Solaris zones and resource management control access to machine resources. For more information, see System Administration Guide: Virtualization Using the Solaris Operating System. environment variablesvariablessystem variablesvariablesname servicesindividual name servicesuser accountsuserssystem securityoverviewmanagingadministeringIn 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.You can control and monitor system access by doing the following:Maintaining Physical Security Maintaining Login Control Controlling Access to Devices Controlling Access to Machine Resources Controlling Access to Files Controlling Network Access Reporting Security Problems accesssecurityphysical security physical securitydescription system securityhardware protection hardwareprotecting system securitymachine access 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.passwordsPROM security modeeeprom commandYou can protect a SPARC system from unauthorized access to the hardware settings. Use the eeprom command to require a password to access the PROM. For more information, see How to Require a Password for Hardware Access. accesssecuritylogin controllogging insecuritysystem access controlpasswordslogin securityYou 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.configuration filesnsswitch.conf filensswitch.conf filelogin access restrictionsWhen 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:files – Designates the /etc files on the local system ldap – Designates the LDAP directory service on the LDAP server nis – Designates the NIS database on the NIS master server nisplus – Designates the NIS+ database on the NIS+ root server accesssecuritylogin access restrictions/etc/nsswitch.conf filelogging insecurityaccess restrictionssystem securitylogin access restrictionsFor a description of the nsswitch.conf file, see the nsswitch.conf4 man page. For information about naming services and directory services, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (NIS+). passwordslogin securityaccesssecuritylogin access restrictionslogging insecurityaccess restrictionssystem securitylogin access restrictionsThe 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.Sophisticated authentication and authorization mechanisms are available on Solaris systems. For a discussion of authentication and authorization mechanisms at the network level, see Authentication and Authorization for Remote Access.passwordslogin securitypasswordssystem loginssystem securitypasswordsWhen 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.Passwords are initially created when you set up a user account. To maintain security on user accounts, you can set up password aging to force users to routinely change their passwords. You can also disable a user account by locking the password. For detailed information about administering passwords, see Chapter 4, Managing User Accounts and Groups (Overview), in System Administration Guide: Basic Administration and the passwd1 man page.passwordslocalIf 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. passwordsNIS+ NIS+ name servicepasswords passwordschanging with passwd -r command r optionpasswd command passwd commandand name services passwordsNISNIS name servicepasswordsIf 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. passwordsLDAPLDAP name servicepasswordsThe 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.In the Solaris 10 release, password policy is enforced on the Sun Java System Directory Server. Specifically, the client's pam_ldap module follows the password policy controls that are enforced on the Sun Java System Directory Server. For more information, see LDAP Naming Services Security Model in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). new featuresstrong password encryptionsecuritypassword encryptionalgorithmspassword encryptionmodulespassword encryptionpasswordsencryption algorithmsencryptionpassword algorithmsystem securitypassword encryptionconfiguration decisionspassword algorithmStrong 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.defaultssystem-wide in policy.conf fileconfiguration filespolicy.conf fileconfiguration filesfor password algorithmsencryptionlist of password algorithmsencryptionspecifying password algorithms in policy.conf fileYou 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.Identifier Description Algorithm Man Page 1 crypt_bsdmd5 password algorithmThe MD5 algorithm that is compatible with MD5 algorithms on BSD and Linux systems. crypt_bsdmd55 2a crypt_bsdbf password algorithmThe Blowfish algorithm that is compatible with the Blowfish algorithm on BSD systems. crypt_bsdbf5 md5 crypt_sunmd5 password algorithmThe Sun MD5 algorithm, which is considered stronger than the BSD and Linux version of MD5. crypt_sunmd55 __unix__ crypt_unix password algorithmThe traditional UNIX encryption algorithm. This algorithm is the default module in the policy.conf file. crypt_unix5 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 # 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__ …CRYPT_ALGORITHMS_ALLOW keywordpolicy.conf fileCRYPT_ALGORITHMS_DEPRECATE keywordpolicy.conf fileCRYPT_DEFAULT keywordpolicy.conf filepolicy.conf filekeywordsfor password algorithmsWhen 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 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. __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. For more information on configuring the algorithm choices, see the policy.conf4 man page. To specify password encryption algorithms, see Changing the Password Algorithm (Task Map). accesssystem loginslogging insystem loginssystem securityspecial loginspasswordssystem loginsTwo 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.group ID numbers (GIDs)special logins andlogging inroot loginaccountroot userlogin accountdescriptionThe 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.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. daemon 1 Controls background processing. bin 2 Owns some Solaris commands. sys 3 Owns many system files. adm 4 Owns certain administrative files. lp 71 Owns the object data files and spooled data files for the printer. uucp 5 Owns the object data files and spooled data files for UUCP, the UNIX-to-UNIX copy program. nuucp 9 Is used by remote systems to log in to the system and start file transfers. 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).deviceslogin access controllogging insecurityaccess control on devices/etc/logindevperm fileBy 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 logindevperm4 man page. dial-up passwordssecurity system securitydial-up logins and passwords 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:d_passwd filedescription/etc/d_passwd fileand /etc/passwd filepasswd fileand /etc/d_passwd filepasswordsdial-up passwords/etc/d_passwd fileIf 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 passwordsdisablingdial-up passwords/etc/d_passwd fileshell commands/etc/d_passwd file entriesDial-up logins are disabled if /etc/d_passwd has the /usr/bin/sh:*: entry only. devicessecurity securitydevices device policyoverview accessrestricting fordevices 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.devicesprotecting in the kernelDevice 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.devicesprotecting by device allocationaccesssecurityperipheral devicesDevice 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. deviceszones andzonesdevices andConfine a device to a particular zone – You can assign the use of a device to a non-global zone. For more information, see Device Use in Non-Global Zones in System Administration Guide: Virtualization Using the Solaris Operating System. For a more general discussion of devices and zones, see Configured Devices in Zones in System Administration Guide: Virtualization Using the Solaris Operating System. new featuresdevice policy device policyoverview 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.For more information about device policy, see the following:Configuring Device Policy (Task Map) Device Policy Commands Privileges and Devices 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.For more information on device allocation, see the following:Managing Device Allocation (Task Map) Device Allocation Device Allocation Commands accesssecuritycontrolling system usage controllingsystem usage 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.accessroot accessmonitoring su command attempts monitoringsu command attempts root usermonitoring su command attempts system securitysu command monitoring accesssecurityroot login tracking logging inroot logintracking logging insecuritytracking root login root usertracking logins 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). system securityrole-based access control (RBAC)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). You can prevent you and your users from making unintentional errors in the following ways:environment variablesPATHYou 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. PATH environment variableand securitysecurityprotecting against Trojan horseTrojan horsevirusesTrojan horseYou 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.accesssecurityPATH variable settingPATH environment variablesettingThe 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. restricted shell (rsh)rsh command (restricted shell)system securityrestricted shellThe 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. > (redirect output)preventingredirecting arrow (>)preventing redirection>> (append output)preventingappending arrow (>>)preventing appendingThe 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.system securityrestricted shellFor information about the restricted shell, use the man -s1m rsh command to see the rsh1M man page. accesscontrol listsACLfilessecurityaccess restrictionBecause 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).accesssecurityfile access restrictionfilessecurityaccess restrictionYou 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. accesssecuritysetuid programssetuid permissionssecurity risksExecutable 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). JASS toolkitpointer to securitypointer to JASS 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. securitynetservices limited installation option securityinstallation options 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 netservices1M and smf5 man pages. securityprotecting against denial of servicevirusesdenial of service attackSolaris 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. 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. accesssecuritymonitoring system usagemonitoringsystem usageAs 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). accesssecuritymonitoring system usagemonitoringsystem usageAs 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). 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).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.crypt commandfile securityencryptingfilesfilessecurityencryptionThe Solaris Cryptographic Framework provides digest, mac, and encrypt commands to protect files. For more information, see Chapter 13, Solaris Cryptographic Framework (Overview). accesssecurityACLs ACLdescription filessecurityACL ownership of filesACLs and permissionsACLs and ACLs, pronounced “ackkls,” can provide greater control over file permissions. You add ACLs when traditional UNIX file protections are not sufficient. Traditional UNIX file protections provide read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides finer-grained file security.ACLs enable you to define the following file permissions:Owner file permissions File permissions for the owner's group File permissions for other users who are outside the owner's group File permissions for specific users File permissions for specific groups Default permissions for each of the previous categories For more information about using ACLs, see Using Access Control Lists to Protect Files. accesssharing filesfile systemssharing filessharing filesand network securityA 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.dfstab filesharing files/etc/dfs/dfstab filesharing filesThe /etc/dfs/dfstab file on the file server lists the file systems that the server makes available to clients on the network. For more information about sharing file systems, see Automatic File-System Sharing in System Administration Guide: Network Services. accessroot accessrestricting system securityroot access restrictions root userrestricting access nobody user 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.An NFS server can grant superuser capabilities on a shared file system on a per-host basis. To grant these privileges, use the root=hostname option to the share command. You should use this option with care. For a discussion of security options with NFS, see Chapter 6, Accessing Network File Systems (Reference), in System Administration Guide: Network Services. accesssecuritynetwork control network securitycontrolling 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 securityoverviewNetwork 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.

Diagram shows three ways to restrict access to remote systems: a firewall system, an authentication mechanism, and an authorization mechanism.

authenticationdescription authenticationnetwork security network securityauthentication network securityauthorizations authenticationtypes authorizationstypes remote loginsauthentication remote loginsauthorization Secure RPCoverview 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.Service Description For More Information IPsec IPsec provides host-based and certificate-based authentication and network traffic encryption. Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services Kerberos Kerberos uses encryption to authenticate and authorize a user who is logging in to the system. For an example, see How the Kerberos Service Works. LDAP and NIS+ The LDAP directory service and the NIS+ name service can provide both authentication and authorization at the network level. System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and System Administration Guide: Naming and Directory Services (NIS+) Remote login commands 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. Chapter 29, Accessing Remote Systems (Tasks), in System Administration Guide: Network Services SASL 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. SASL (Overview) Secure RPC 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. Overview of 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. NFS Services and Secure RPC Solaris Secure Shell Solaris Secure Shell encrypts network traffic over an unsecured network. Solaris Secure Shell provides authentication by the use of passwords, public keys, or both. Solaris Secure Shell uses RSA and DSA authentication for public keys. Solaris Secure Shell (Overview) Secure RPCalternativeprivileged portsalternative to Secure RPCA 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” gatewaysfirewall systems system securityfirewall systems accesssecurityfirewall setup Internet firewall setup firewall systemssecurity 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.packet transfersfirewall securityaccesssecurityfirewall setupnetwork securityfirewall systemsneed forA 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.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. firewall systemstrusted hostshoststrusted hostsnetwork securityfirewall systemstrusted hoststrusted hostsA 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. IPsec and Solaris IP filter can provide firewall protection. For more information on protecting network traffic, see Part III, IP Security, in System Administration Guide: IP Services. firewall systemspacket smashing network securityfirewall systemspacket smashing packet transferspacket smashing firewall systemspacket transfers 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.To encrypt remote operations over an insecure network, see Chapter 19, Using Solaris Secure Shell (Tasks). To encrypt and authenticate data across a network, see Chapter 21, Introduction to the Kerberos Service. To encrypt IP datagrams, see Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services. network securityreporting problems accesssecurityreporting problems Computer Emergency Response Team/Coordination Center (CERT/CC) 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.