A Practical Guide to Solaris Security pdf

Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 1
A Practical Guide to Solaris Security
A White Paper
March 1994
Synopsis
This white paper aims to provide practical security guidelines for the Solaris operating system
(supplied by SunSoft). It focuses on the Solaris 2.3 version, however, references are made to
Solaris 1 in-order to illustrate the improvements.
Who should read it? This paper assumes some knowledge of Solaris and is suitable for anyone
who has completed the ‘Solaris2.x System Administration’ course and would like to know
more about Solaris2 security features.
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 2
Contents
1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 EEPROM Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 Login Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Compromised Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
6.2 Good Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3 Missing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4 Password Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
6.5 Direct root login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.6 Password Cracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.7 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.8 Shell Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
6.9 The Swap User Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.10 Modem Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Basic file permissions revisited . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 UMASK Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3 Automatic Start-up Wrappers. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.4 Setuid programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.5 Setuid Shell Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
7.6 Shared Library Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.7 Hidden directories and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8 X11 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.9 Loading files from Media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.10 Device Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8 Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1 Machine cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
8.2 Network Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
9 Network Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1 Secure RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2 DES Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3 Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 3
10 Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1 NFS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2 inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.3 in.routed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.4 sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.5 Remote Access Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11 Public Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1 Automatic Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.3 Ftp & Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

12 Network Information Services . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1 Solaris1 & Solaris 2 NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.2 Moving NIS Map Source files . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.3 Solaris 2 & NIS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13 Logs & auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
13.1 Console Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.2 BSM auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
13.3 The system logger “Syslog” . . . . . . . . . . . . . . . . . . . . . . . . . . .36
13.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14 Unbundled products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.1 History of Solaris Security Products . . . . . . . . . . . . . . . . . . . . . 38
14.2 Automatic Security Enhancement Tool (ASET) . . . . . . . . . . . . 38
14.3 Account Resource Management (ARM) . . . . . . . . . . . . . . . . . . 39
14.4 Compartmented Mode Workstation (CMW) . . . . . . . . . . . . . . . 39
15 Hackers toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1 Trojan Horse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
15.2 Trojan Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
15.3 Viruses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.4 Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.5 Back Doors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix A: Crack programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix B: Net Groups and NetIDs . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix C: Third Party Products Mentioned . . . . . . . . . . . . . . . . . 44
Appendix D: References and Further Reading . . . . . . . . . . . . . . . . . 44
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 4
1. Executive Summary
The UNIX* operating system is generally perceived to lack adequate security. This is partly due
to its academic origins and partly due to its design goal to be inviting and flexible. As UNIX

has matured more security features have evolved and today UNIX can provide similar levels of
security to those found in proprietary systems.
One of the main objectives of Solaris 2.3 is to take UNIX further into the commercial market-
place where good security is a major concern. Many new security features have been included
in Solaris 2.3 to achieve this goal. As an example, Solaris 2.3 has a “Basic Security Module”
which has “audit trail” functionality mandated by government groups.
For some organisations security is important but not paramount. They wish to have a reasona-
bly secure system without losing the flexibility that attracted them to UNIX. The Solaris2 ‘aset’
command has been included for this type of user.
2. Overview
This document guides the system administrator thought the issues of system security. Each sec-
tion provides examples of the command used to setup the security feature. Information on the
important system files and commonly made mistakes have been highlighted. At the end of each
section a reference to the relevant Solaris manual set is provided for further information.
This document details several methods of attack and tools that are used to gain unlawful access
to computer systems (“hacking”). This information will prove useful to enable the system ad-
ministrators to guard against hacking.
Getting Help
Following the guidance of this document will result in a much tighter security for your system.
however no system can be considered totally secure. Sun have setup a Security Awareness Pro-
gram. As part of this an email alias “” is available for customers to
track/report new security issues. It is important to know that Sun will provide security patches
to anyone who requests them, even if they do not have a maintenance contract.
3. Introduction
The dictionary defines secure as: to make safe from risk or damage; to guarantee against loss.
The word security is defined as: freedom from danger, fear, or anxiety; protection: measures
taken to protect against espionage or sabotage.
All these definitions of security apply to computer systems. We need to physically protect our
computers from damage.We need to guard against loss of data as well as illegal access.
UNIX* - Is a trademark of X/open

Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 5
An organisation’s primary concern is the protection of its data rather than it’s computers sys-
tems. Preventing unauthorised access is just a means of protecting data. The loss of CPU time
and disk space is not the main concern, data integrity is. Figure1 illustrates that the majority of
data damage is caused by error rather than malicious intent. It is clearly a security prerequisite
that a thorough backup strategy and comprehensive disaster recovery procedures exist.
The task of protecting data involves more than making secure backups and preventing outsiders
from logging in. Figure2 illustrates that computer crime is predominately committed by em-
ployees. Account security is just the perimeter fence. It is important to protect users from each
other with good file system security.
As with all crimes, increasing the likelihood of being apprehended is the best prevention. Au-
diting provides the weapon to make users accountable for their actions.
Fig1: Causes Of Data Damage
52% 15% 10% 10% 10% 3%
Human Error
Fire Water Sabotage Crime Terrorism
Disaster Recovery 77% Security 23%
source: Data Processing Management Assoc 1992
Fig 2: Perpetrators Of Computer Crime
Employee
Former Employee
Outsider
81%
13% 6%
Login Security 19%Audit Security 81%
source: Data Processing Management Assoc 1992
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 6

4. Physical Security
“A computer is only as secure as the room it’s locked in?”
The problem is that anyone with physical access to a machine can bring along their own disk
and connect it. Then it’s a simple matter of crashing the machine and booting from this disk.
Once the system is up and running on their disk, the file systems on the original disks can be
mounted and tampered with.
This would be even easier if, like most SPARCservers, the machine had a CD-Rom player at-
tached. In this case all that is required is a copy of the Solaris CD. The system is booted from
the CD into single user mode where access to resident disks can be obtained. The machine’s
operating system could even be reinstalled!
The solution to this scenario is found in section 5 ‘EEPROM security’. However even if the
EEPROM will not let them boot an external disk, cables and SCSI switches can be changed to
make the new disk appear to be the old disk.
So to prevent this tampering with cables, the machines cabinet needs to be locked. Larger Sun
Servers have keys which need to be turned for the boot sequence to start but most are left in for
convenience. Sun’s Data-centre cabinets also have connections for an electronic key on the
back of the power supply, but few people utilise this.
Servers can be locked in computer rooms. However desktop systems often cannot. For example
a teaching laboratory environment. It is possible to secure the CPU box to a desk as all desktop
Suns have a bolting point integral to the system. This not only safe guards against theft of the
box but also prevents the lid from being opened and memory or disks removed.
It may just be the intention of the assailant to crash the system. It’s difficult to prevent someone
pulling out the power cable. However other ways of crashing the machine such as the “stop-a”
sequence and unplugging the keyboard cable can be prevented by modifying the kernel.
A similar problem is faced with the serial cable to console terminals. Switching the console ter-
minal on/off will cause a server to crash. It may even be worth buying a graphics head for your
server to side step this potential hazard.
In conclusion machines with important data should be locked in a computer room - even if they
don’t need air-conditioning.
!

Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 7
5. EEPROM Security
All Sun system CPU boards have an EEPROM. This EEPROM contains the ‘monitor’ program
which controls the system during startup. When a machine is powered on, the monitor firmware
will automatically run system diagnostics then boot the system. If this boot sequence is inter-
rupted with “stop-a” (the break key if the console device is a dumb terminal), then the machine
will be left with the monitor’s interactive prompt:
“ok”
From this prompt you can instruct the monitor to boot the system from any device: CD-Rom,
external disk or even another machine on the network. To limit this, the monitor has three se-
curity modes none-secure (the default), command-secure and fully-secure.
In fully-secure mode a password, known as the “EEPROM-password” has to be given before
the monitor will boot anything. This is a little inconvenient on desktop machines which are
prone to being accidentally halted or crashed. The automatic reboot feature would be interrupt-
ed with a prompt for the EEPROM password. To alleviate this the command-secure mode can
be used which allows only the boot command ‘b’ to be executed without entering the EEPROM
password. A suitable policy would be to set server systems to fully-secure and client worksta-
tions to command-secure. For example:
ok# setenv security-mode=command
passwd = <type your password>
ok# printenv
A nice feature of the “monitor” is the ability to change the power on logo which normally dis-
plays the machine’s serial number. You can set this to identify the machine as belonging to your
organisation. This would reduce the likelihood of a thief finding a buyer. As long as the EEP-
ROM password was set he could not change this banner message. Note however if the EEP-
ROM password is not set a thief could disguise the serial number. An Example:
ok# setenv oem-banner?=true
ok# setenv oem-banner=”THIS IS MY MACHINE”
ok# printenv

It is possible to reset the EEPROM password without knowing the old password. As long as the
machine is up and running the root user can change EEPROM password with the “eeprom”
command:
# eeprom security-password=
Changing PROM password:
New password:
If you forget the EEPROM password with the security-mode set to full and the machine is halt-
ed you will not be able to reboot the machine. The only way then, to reset the EEPROM pass-
word would be to change the EEPROM chip itself, which on some machines means changing
the CPU board.
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 8
There is also a way to see if anyone has attempted to break into the EEPROM. A variable called
“security-#badlogins” keeps a count of the failed attempts. It can be set to zero by typing:
# eeprom security-#badlogins
security-#badlogins=0
Early versions of the ‘Open Boot Prom’ (Version 1.x) had a security problem with specific
break sequence. This has been fixed in Version 2.x. If you have one of these older EEPROM it
should be replaced. Sun’s customer services should be contacted for advice on your particular
machine. To display EEPROM revision type “banner” at the “ok” prompt.
Accidental Interrupts
No matter which security mode you have set, it is always possible to use the continue command
“go”. This assumes the machine has not been turned off. As long as the memory and CPU reg-
isters have not been altered the machine will resume execution at the point that it was interrupt-
ed. this is the first thing to try if the break sequence has been used accidentally. Users should
be informed of this to prevent the system administrator having to attend every accidentally halt-
ed machine.
NOTE: If the EEPROM is in ‘old-mode’, the user will be prompted by the ‘>’ character instead
of ‘ok’. In this case the ‘c’ command is used instead of ‘go’. Alternatively to obtain an ‘ok’

prompt the command ‘new-mode’ is used.
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 9
6 Login Security
For the moment we will forget the complications of network authentication systems like NIS
and NIS+ (see section 12) and concentrate on accounts and their associated passwords.
6.1 Compromised Passwords
The simplest way to gain illegal access to a machine is by obtaining a valid user’s password. A
password might be guessed though personal knowledge of the account holder, or discovered
written on paper or even written in a file on another system. A common hacking technique is to
search email folders for account names and passwords. It’s bad practice, but often users are giv-
en their account details to a new system by email. If the new account is little used, rather than
remember this additional password, some users save the email or commit it to a file. It may be
a low privilege account but it could often be the door for a hacker to greater things. There are
many other factors that drive users to committing their password to paper/disk:
1. They have a too many different passwords for too many different machines.
2. For the password to be any good it has to be unintelligible and thus difficult to remember.
3. The administrator makes the users change their password too often.
4. The administrator allocates computer generated passwords impossible to remember.
We can do much to prevent a password being discovered, not least by choosing better pass-
words, but there is little we can do if users feel they have to write them down in order to re-
member them. With this respect you are left at the mercy of the users.
6.2 Good Passwords
A good password is meaningful to the user but nonsensical to anyone else. No word found in a
dictionary is good enough thanks to programs like “Crack” (See appendix A). Solaris 2.3 has
some new features which help users create good passwords. Users run the command “passwd”
to change their passwords. Under Solaris 2.3 new passwords are vetted by “passwd” before be-
ing accepted. It checks that:
1. The password is greater than six characters. (Configurable in the /etc/default/passwd file).
2. The password has at least two alphabetical and one non-alphabetical characters

3. The new password is not the same as the old password.
4. The password is not the same as the user name.
Unlike Solaris1, insisting on a rejected password will not result on the password being accept-
ed. Note: “passwd” will not object to any password set by root as it is assumed that the root user
knows best.
6.3 Missing Passwords
Its a bad idea to allow accounts to have no password. By default, Solaris2 forces all accounts
to have a password. To confirm this check that the PASSREQ (PASSword REQuired) parameter
in the /etc/default/login file, is set to YES.
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 10
6.4 Password Administration
Solaris 2 has a number of new features for setting password policies. These are set as fields in
the /etc/shadow file. On a per user basis the following can be defined:
username:passwd:lastchg:min:max:warn:inactive:expire
Username: must match a line in /etc/passwd
passwd: encrypted password
lastchg: number of days between 1/1/70 and last change of password
min: minimum number of days between password changes
max: maximum number of days between password changes
warn: number of days before password expires a warning is given
inactive: number of days of inactivity allowed before account is locked.
expire: date when account will expire
All the above fields can be changed with the /usr/bin/passwd command. Its always best to use
commands like passwd or use admintool to set these properties as hand editing the shadow
password file can result in catastrophe if typing mistakes are made. Solaris1.1 did have a pass-
word aging facility but it was not compatible with NIS and was little used. Note: Default poli-
cies for password aging are defined in “/etc/default/passwd”. (See man page for passwd (1)).
Locking Accounts and Passwords

Solaris 2 gives us the facility to lock an account.There is even a way to prevent users from
changing their passwords. By setting ‘min’ greater than ‘max’ the user can still login but not
change his password. Useful for allocating password rather than allowing users choose their
own. Here are some examples:
# passwd -l <user> Lock an account
# passwd -n 10 -x 7 Lock a password
# passwd -f <user> Change password on next login
# passwd -n 30 <user> Change password every 30 days
Remember: don’t enforce too strict a regime, as it will force users to write down their pass-
words. Passwords are your first and most important line of defence and any one user can be the
weak link in the chain. Education of users rather than enforcement of rules is the key to good
password security.
6.5 Direct root login
Any user with the UID of 0 (often called the Superuser or root) is granted full access to all files
on the system despite any access permissions set-up by the file’s owner. The superuser’s name
may not necessarily be called “root” and in fact several user names could have a UID of 0. This
is an important thing to remember when looking for evidence of hacking.
Given it’s awesome power it’s a good idea to restrict the activities done as root. Most system
administrators login directly as root as a matter of course, because they believe that root privi-
leges are needed to perform their tasks. Not so, in Solaris 2 group 14, often named “Sysadmin”,
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 11
gives it’s members the privilege to perform system administration tasks using Admintool. (See
section 6.7 Groups).
Its best not to let anyone login directly as root. System administrators should discipline them-
selves to login with their own user credentials then switch user (su) to root. This also has the
advantage of leaving better audit trails if a system is managed by more than one person. This
regime is also good for eliminating those catastrophic mistakes that commonly resulting from
wildcard activity as root.

Solaris 2, by default, doesn’t let root login anywhere except the system console. This is con-
trolled by the following line in the /etc/default/login file:
CONSOLE=/dev/console
If the console is locked in the computer room with the machine then the default setting is ap-
propriate. However for a workstation it would be better to disable root login completely by set-
ting console to the null device:
CONSOLE=/dev/null
If the console is not set, then root will be able to login from anywhere, even remotely from other
machines.
6.6 Password Cracking
The Solaris 2 login program will only allow five failed attempts to login before it suspends the
login port for 5 minutes. This prevents a password being guessed by trial and error. A hacker
could make several informed guesses but try only 5 at a time. More importantly this stops a pro-
grammatic approach of trying every word in a dictionary. It could still be attempted but would
take too long. Hopefully the system administrator would notice such prolonged activity.
If five failed attempts are made, syslogd (See section 13.3) will send an alarm message to the
console. However, it records little information about the suspected break-in attempt. More in-
formation can be recorded by enabling the login log:
#touch /var/adm/loginlog
#chmod 600 /var/adm/loginlog
#chgrp sys /var/adm/loginlog
Note: It is not until the fifth attempt fails that anything is written to the login log. This means
four attempts can be made without being detected. There have been many request that SunSoft
make the number of allowed failure configurable.
!
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 12
Encrypted Passwords
Because of password cracking programs (See Appendix A), its a bad idea to let the world see

even your encrypted passwords. If hackers can take a copy of the encrypted passwords then
they can attempt to crack them on their own machine at leisure and in secret.
To prevent this Solaris 2 has a shadow password file. UNIX requires the account information
to be globally accessible. This means that the /etc/passwd file must be readable by everyone. In
Solaris 1 encrypted passwords were stored in this file too. In Solaris 2 the /etc/passwd file still
contains the account information but passwords and associated information is kept in /etc/shad-
ow file. i.e.:
-rw-r r 1 root sys 508 Jan 28 15:53 /etc/passwd
-r 1 root sys 279 Feb 1 12:33 /etc/shadow
6.7 Groups
It is not just illegal root access that must be guarded against. Often being a member of a special
group can be enough to severely compromise security. A user can be a member of one or more
groups. A user’s primary group is specified in the /etc/passwd file. Secondary group member-
ship is defined in the /etc/group file. Both primary and secondary groups are used when deter-
mine file access. Some security conscious applications will only consider a users primary group
when determining privilege. However users can make any of their secondary groups their pri-
mary group by using the “newgrp” command.
Group Passwords
Some older UNIX system made use of the group password facility, where users can swap to any
group provided they knows the group password. When a user swaps to one of his secondary
groups, no password is required. Solaris 1 and Solaris 2 have this functionality, but no use is
made of it and there is no command to set a group password. However one could be written if
this functionality was desired. Copying an encrypted password string from the /etc/shadow file
and inserting it into the password field of the group file will work.
Sys (group 3)
There are several powerful commands that can be executed by anyone with group ID of 3, (GID
3). The most important being ufsdump. The idea being that operators can perform a backup
without knowing the root password. This has its advantages, but remember anyone who can run
dump can steal data. A dump tape can be restored on another machine where the thief does have
root privileges. Note: Under Solaris1 dump and shutdown could be run by anyone in the oper-

ator group (GID=5).
Wheel (group 0)
Under Solaris1 the GID of 0 (know as the root or ‘wheel’ group) gives a list of users that can
run “su”, the swap user command. However if the group was not defined then any user was en-
titled to run “su”. The “Wheel” group feature has been removed in Solaris 2. However if this
functionality is required it could easily be setup by creating your own wheel group then:
# chgrp wheel /usr/bin/su; chmod 510 /usr/bin/su
NOTE: a version of su exists in /sbin as well as /usr/bin. So access to both needs to be consider.
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 13
SysAdmin (group 14)
Anyone in the sysadmin group can run Admintool and perform system administration tasks
such as add/delete users or reseting printers. It is even possible to delete and recreate the root
account with a new password! So tight control is necessary over group 14 membership.
Admintool is network extensible and can be used to modify remote machines as well. It can be
set up to use different levels of network authentication. This level can be changed by editing
the /etc/inetd.conf file and running “admind” with the -S option:
100087/10 tli rpc/udp wait root /usr/sbin/admind admind -S 2
You do not need to maintain the same level of security on all systems. It might be a good idea
to run level 2 security on servers and the default, level 1, on workstations. Level 1 means the
hosts “admind” will accept the user and group identities directly from the client system. If the
user is in group 14 then he has admintool powers. Watch out for level 0 where no identity check-
ing is done. Note, ’-S 2’ option requires DES authentication to be set up - (see section 9.2)
6.8 Shell Security
There are many command interpreters (Shells) to choose from. The login program puts users
into their default shell which is specified in the /etc/passwd file. In Solaris 2 users can no longer
change their default shell. It was possible to do this with the passwd or chsh commands in
Solaris1. Types of new shells could be restricted by creating a list of allowable shells in the ‘/
etc/shells’ file.
Preventing users from changing their default shell means that the system administrator can de-

termine which global startup file they run and use it to enforce policy. For the bourne (sh) and
korn (ksh) shell this is /etc/profile. Solaris1 had no such file for the C-shell (csh) however the
Solaris 2 ‘csh’ now uses the /etc/.login file for this purpose.
These files are a good place to set users up with some healthy defaults for shell variables such
as PATH,UMASK or LD_LIBRARY_PATH. The administrator can now mandate which shell
the users enter by and hence which startup file they will execute.
The Command Path
Which version of a command a user executes is determined by the setting of his environmental
variable “PATH”. It’s a security risk to have a “.” in a users command path. This tells the shell
to look in the current directory for commands. The user may think he is executing /usr/bin/ls
when really he is executing. “./ls” left by a hacker (see section 15.1 - trojan horse). If “.” must
be in a PATH then put it at the end. It is most important not to have “.” in the root’s PATH. It
might even be a good idea not to have a root path defined. This way the root user has to type
the full pathname (/usr/bin/ls). A little realised fact is that a ‘:’ at the beginning or end of the
path has the same meaning as “.”. So does an empty field ‘::’, so check for these as well.
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 14
Restricted Shells
It is a security risk to have “guest” accounts where anyone can login. These usually have ac-
count names like guest, visitor, demo or temp. These are the first names a hacker will try. If val-
id users cannot be given their own accounts then it is possible to restrict activity on guest
accounts using restricted shells.
Solaris 2 has specially provided restricted shells “/usr/lib/rsh” and “/usr/bin/rksh”.The first is
not to be confused with the BSD remote shell command /usr/bin/rsh. If these are defined as the
default login shell in the password file then the guest users are prevented from:
1. Changing directory
2. Setting the command path
3. Using shell redirection. (i.e. >, >>)
Command use can be limited by putting only the allowed commands in the special “./bin” di-

rectory and setting the path appropriately. It is very important to vet every command you place
in the restricted bin directory. A classic mistake is to let users run “vi”. Once in “vi” its a simple
matter to spawn a normal shell using “!sh” for example.
If the purpose of the account is to share files with absolutely anyone then an anonymous ftp ac-
count would be better. Rather than allowing users to login, let them interact with your ftp dae-
mon. (See section 11.3 ftp & telnet).
6.9 The Swap User Command
The “su” command allows any user to change his UID to another user provided he has knows
the users password. This is potentially a very dangerous command. In fact if you are root you
can “su” to another user without knowing his password. The reason being that if your root ac-
count is compromised then the system is lost anyway so what does it matter? It matters when
NFS is involved, (see Section 10.1 - NFS security).
It seems prudent to monitor the use of such a powerful command. Solaris 2 has a much more
extensive and flexible “su” logging facilities. The file /etc/default/su contains the following pa-
rameters:
SULOG: Defines log file
CONSOLE: Which screen to send messages to; If any.
PATH: Default path for new shell
SUPATH: Default path if su is to root
SYSLOG: whether or not to send signals to syslogd
As with Solaris1, reports of “su” activity are sent to the system logger (see section 13.3 syslogd)
and as a result messages end up on the system console. Additionally, in Solaris 2 all “su” activ-
ity is logged to /var/adm/sulog (The default setting for SULOG). If syslogd is not running then
messages can be sent directly to the console device by defining CONSOLE in /etc/default/su. t
There seems little point in defining PATH and SUPATH as users can simply set their own after
“su-ing”.
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 15
Auto Logout / Lock Screen

Users are prone to walk away from their screens without logging out. An opportunist could
quickly give himself permanent access to that user’s account.(Note: he would not be able to find
or change the absent users password, as the old password is needed to change to a new pass-
word). It therefore might be a good idea to automatically logout users after a period of inactiv-
ity. This also helps with machine performance. An autologout program is not included in
Solaris however public domain versions exist. On such program is called “untamo” and can be
obtained from several internet sites by anonymous ftp.
Untamo is only effective with terminal based users. It is not so easy to write such a program for
an X-windows based user as inactive sessions can often be windows that need to be left open.
The answer in this case it to force users to run a screen locking program. (See Section 7.8 - X-
Window Security)
There is however an inherent danger with automatic logout programs in the time it takes them
to notice inactivity and take action. This leaves a window of opportunity for a hacker not only
to resume the session before inactivity time is reach but to leave a “trojan mule” (See section
15.2). It is much better to educate users to logout every time they leave their desks.
6.10 Modem Security
Connecting a modem to your system makes it prone to attack from any schoolboy hacker with
a PC at home. Serious consideration is required before attaching a modem. If you do need the
use of a modem maybe it can be setup for dailout only. If dial-in functionality is necessary a
dial-back regime is recommended. This involves terminating all calls after the user has identi-
fied himself. The system will then dial him back on a number stored by the system administra-
tor. In this way only registered phone numbers can establish connections. The disadvantage
being that the call is now outgoing for telephone charging purposes. Solaris 2 has no dial-back
facility as standard. However a third part product called “TermServ” can be purchased and is
used by Sun. (See Appendix C-Third Party Products). If full bidirectional functionality is re-
quired then Solaris 2 has an additional “port passwords” feature that can help.
Port Passwords
The Solaris 2 login program can be setup to prompt for an additional password when users con-
necting over dialup lines. Although this feature may have been intended for additional security
to dialup lines, you can enable this for any tty or pseudo tty access (i.e. via telnet, rlogin or any

process using tty-like behaviour). (See Sol2.3 Administering Security, Performance & Ac-
counting - page 13)
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 16
7. Application Security
7.1 Basic file permissions revisited
Everyone thinks they knows what the UNIX file permissions mean. But it might be worth going
over this one more time for reference sake. These are well understood for regular files but there
is often confusion over their meaning when set on a directory.
For a directory:
d-w Files can be created/deleted, only if the directory is the current directory.
dr The contents can be listed but file attributes can’t be read (‘ls -l’ doesn’t work).
d x The directory can be entered, and used in full execution paths.
dr-x File attributes can now be read (‘ls -l’ now works).
d-wx File can be created/deleted, even if the directory isn’t the current one
d x-t Prevents files from deletion by others with write access. Used on /tmp.
d s s No effect. (Note: the setgid bit had some meaning in Solaris 1.x).
for regular files:
-r Allow read access to the file
w Allows the user to modify, or delete the file
x Only the owner can execute files (Not shell scripts)*
s Will execute with effective user ID = owner (See section 7.4)
s Will execute with effective user ID = group (See section 7.4)
-rw T No update of “last modified time”. Usually set on swap files
t No effect. (Note: Called the sticky bit had some meaning in SunOS 3.5)
rwl The file must be locked before reading or writing.
* Note: Shell scripts need read as well as execute permissions to be run.
7.2 UMASK Setting
UNIX file permissions are a user’s first line of defence, but are often over looked. Files are cre-

ated without regard to their permissions setting. If files are created without explicitly specifying
any permissions then they will get the default permissions defined by the user’s “umask”. The
standard umask,022, leaves files readable by the world a more secure umask would be 077:
Using umask 022 gives new file -rw-r r permissions
Using umask 077 gives new file -rw permissions
Table 1:
special owner group other
s s t r w x r w x r w x
4 2 1 4 2 1 4 2 1 4 2 1
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 17
Its a good idea to set system wide umask in /etc/profile and /etc/.login. (See “Setting Default
file permissions Solaris2.3 Advanced User Guide page 151)
Device File Permissions
Close attention must be given to the permissions on the files in the /dev directory. Anyone who
has access to /dev/dsk/c0t0d0s0 has access to any part of the file system mounted on it.
If this is the root file system the /etc/shadow file could be examined/altered e.g.:
dd if=/dev/dsk/c0t0d0s0 | grep shadow
When a user logs in, the login program will change the owner and group of the device file to
the UID of the successfully logged in user. It will also change the GID to “tty”. It then changes
its permissions to “crw w ”. This prevents other users interfering. This default behaviour can
be changed by editing the “/etc/logindevperm” file. This file has great potential for letting other
users eavesdrop on private sessions.
7.3 Automatic Start-up Wrappers
It is an inconvenience for users to have to login to UNIX and then login to the application/da-
tabase. In some implementations all users login with the same UNIX username and rely on the
database’s user registration for security. This is never a good idea but often done.
Smarter implementations will match the UNIX username to the database user name and have
tools for the database administrator (DBA) to create/remove accounts. Adding a user with such
a tool will create a UNIX account and DBMS account simultaneously with an identical pass-

word (known as ‘password pass-through’).
“Turnkey” systems try and shield the users from UNIX by logging them straight into the appli-
cation. Where a system is used in this way it is important that users are not able to break out
into a UNIX shell. There are several ways of preventing this. The best way of doing this is not
to run a shell at all. The application program can be invoked directly by placing the name of the
executable in the password file instead of a shell.
Because, some applications need environmental variables setting up correctly before they can
be run implementors setup the application to run from the user’s “.profile”. It would better to
create a wrapper (shell script) and place it in the user’s default-shell field directly.
Interrupting Shell Scripts
It is possible for users to interrupt the processing of shell script and indeed the.profile. A user
can quickly type an interrupt signal (such as control C) which will leaving him in his default
shell. To stop this the “.profile” must intercept such interrupts with the “trap” command. Also
when called from a shell a binary will run in its own shell. This shell could also be interrupted.
It is possible to prevent this by running the binary without a shell using the “exec” command.
e.g.:
%cat.profile
trap exit 0 2 3 4 5 6
PATH=/home/apps/bin; export PATH
APHOME=/home/apps; export APHOME
exec /home/apps/bin/program
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 18
Even if trap is used as the first line of a shell script, it is possible for a lucky hacker to hit an
interrupt just as the login program starts to read the .profile and get in before trap has setup the
signal masks. The csh equivalent to “trap” is “onintr” but by default the csh ignores interrupt
signals when it is reading the “.login” file. In this respect the csh is more secure than the bourne
and korn shell.
Many database management systems allow users to spawn a UNIX shell from their menus. This
must also be considered. Many UNIX utilities allow the user to execute a shell command from

within them. An example being the ‘:!sh’ command in vi. (See section 15.5 - Back Doors).
7.4 Setuid programs
If an executable file has its setuid bit set then it will run with the “Effective User ID” (EUID)
of the file owner. This might seem too powerful a facility and you may question why it is nec-
essary?
The user’s real ID (UID) can still be determined. Security conscious programs will check the
UID to see if it is different to the EUID (See Section 7.5 Setuid Shell Scripts). However the
UNIX file system accept EUID credentials in the same way as UID.
This facility is often used by multiuser applications to access files owned by others. The Oracle
server program is an example of this. A simpler example is the “passwd” command. We want
users to be able to change their passwords, which requires “write” access to /etc/shadow. How-
ever, we do not want them to write anything they like. So only root has write access to /etc/
shadow. If users want to change their password they must run “passwd” with effective user id
of 0:
% ls -l /etc/shadow /usr/bin/passwd
-r 1 root sys 508 Jan 28 15:53 /etc/shadow
s s x 1 root sys 11492 Sep 27 15:35 /usr/bin/passwd
The same facility is available for group access known as set effective group id (EGID).
The setuid/setgid facility is often abused. If a hacker cannot become a user (root being the big-
gest prise) then he maybe able to run programs as that user. If he can gain an euid of 0 then its
possible, among other things for him to edit the password file and setup his own account with
uid of 0.
7.5 Setuid Shell Scripts
Shell scripts can be made to run EUID and EGID as well as binary files. Setuid shell scripts are
VERY insecure as it may be possible to interrupt them potentially leaving the user in a shell
with root privileges! Different shell programs handle set EUID in different ways:
Bourne Shell (sh)
The bourne (sh) protect against this hazard. By default a bourne shell script will ignore EUID
and EGID by setting them back to UID and GID respectively. However this feature can be dis-
abled by invoking the shell with the “-p” option.

!
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 19
Korn Shell (ksh)
The korn shell does not have this feature. However it does read /etc/suid_profile if EUID is not
equal to UID or EGID is not equal to GID. The manual pages indicate that “-p” will force EUID
to be reset to UID, but this is not the case.
C-Shell (csh)
The C-shell will not allow script files to be executed setuid or setgid, giving a “permission de-
nied” message. However, calling the C-shell with the ‘-b’ option overrides this security feature.
Interactive Setuid Shells
It is even possible to get an interactive shell to effectively run as root. One way to do this is to
make a copy of the shell program itself (/usr/bin/sh). Change the ownership to root and change
the permission to setuid. Any user who runs this shell will have EUID = 0. This could only be
done as root but there are ways to get a root user to inadvertently run these commands for you
(See section 15.1 on Trojan horses and Section 9.4 NFS Client Security).
It is therefore a good idea to keep a list of all legitimate setuid files and frequently check for the
appearance of new ones. this can be done with a “find”.The following will list all setuid and
setgid files:
find / -user root \( -perm -4000 -o -perm -2000 \) -ls
The Solaris 2 ASET program does this automatically. see section 14.2.
7.6 Shared Library Security
Shared libraries are in common use both in Solaris1 and Solaris 2. Their great advantage is that
they cut down the memory usage. Where programs use the same library function they don’t
each have to keep their own copy in memory. Most of the commands in /usr/bin use shared li-
braries. These executables are described as being dynamically linked. A service called “The
Runtime linker” will connect them to the appropriate shared libraries when they are executed.
The ‘ldd’ command can be used to find out which shared libraries a program will use when ex-
ecuted:

% ldd /usr/bin/ls
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
A user could create his own subversive version of these shared libraries and alter his library
path to point at his version:
% touch /tmp/libc.so.1
% setenv LD_LIBRARY_PATH /tmp
% ldd /usr/bin/ls
libc.so.1 => /tmp/libc.so.1
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 20
libdl.so.1 => /usr/lib/libdl.so.1
Not so crucial for the ls command but if it was a setuid program then the creator of the new
library could execute any piece of code he wanted as another more privileged user.
It is possible to dynamically link a program such that it ignores LD_LIBRARY_PATH using a
new environmental variable ‘LD_RUN_PATH’ in Solaris 2:
% setenv LD_RUN_PATH /usr/lib
% unsetenv LD_LIBRARY_PATH
% cc -o prog prog.c
Now if “prog” has its setuid bit set, LD_LIBRARY_PATH will be ignored. All the standard se-
tuid programs in /usr/bin have been written with shared library security in mind and have been
compiled in this way. It would be a good idea to check which of your third party applications
that runs setuid also ignore LD_LIBRARY_PATH by using the ldd command.
Solaris1 setuid to root programs also ignored LD_LIBRARY_PATH, but it was not so easy to
create our own programs to do so.
7.7 Hidden directories and files
Public read/write directories suffer from this activity. Anonymous-ftp accounts are often used
in this way where hidden directories are used to share software in breach of copyright. Alter-
natively hidden directories might be created in /var/tmp and contain a “hacker toolkit” (See sec-

tion 15).
Where has all the disk space gone?
There is a directory there but you cannot see it. The ’ls’ command ignores files beginning with
“.”. But this can be over come with ‘ls -a’ option. Its a good idea to alias ‘ls’ to “ls -a” to make
this the default for root. A classic directory name is <space>. A telltale signs is unusual format-
ted output such as an extra linefeed when running “ls”. A really clever directory name would
include escape sequences to clear the last line of the screen. Here are some common examples:
mkdir .\<space>
mkdir \.\.\.
mkdir ^v^z
The best way to find out the name of a hidden directory is to run “ls -aR” which will list the
contents of all directories. This assumes that the files within the directory haven’t also got non-
printing names. The best way to find out what obscure characters make up these file/dir names
is to run ls -aR while in a script session (/usr/bin/script). The script file can be edited with “vi”
which highlight non-printing characters with the quote symbol “^V”. Alternatively, use the ‘-
b’ option to ‘ls’ to display non-graphic character in octal notation. This does not include white
space characters such as tab, space or linefeed.
Missing space could of course be being used by an unlinked inode which is being held open by
some process. So don’t get too paranoid! Running fsck can confirm this for you.
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 21
7.8 X11 Security
One of the features of X-based window systems, is to allow users to run their programs on one
system and display the output on another system. This leads to many security implications.
OpenWindows3.3 supports two different access control mechanisms: user-based and host-
based. The older host based mechanisms are used for backward compatibility with earlier X11
releases.
The host based mechanism is weak because if you grant access to another host then all the users
on that host can access your X-Server. The new user-based or authorisation-based mechanism

allows you to explicitly grant or deny access to any given NetID. (see appendix B).
There are two types of user-based protocols: MIT-MAGIC-COOKIE-1 and SUN-DES-1. The
MIT version is used as default by OpenWindows. However SUN-DES-1 is much more secure,
as it uses secure RPCs.(See section 9.1). Here is how you select the authentication mechanism
your require:
“openwin” MAGIC-COOKIE authentication
“openwin -noauth” host based authentication
“openwin -auth sun-des” SUN-DES authentication
With MAGIC-COOKIE access information is kept in a users’ ‘.Xauthority’ file found in their
home directory. This file should be kept read/write by the owner only. If someone gains access
to this they gain access to your screen and effectively access to anything you type or view. The
“.Xauthority” file can be manipulated by the “xauth” or xhost command. Users should be dis-
couraged from using the wildcard “+” with these, such as:
%xhost +
Which allows anyone to access the X11 server. The xhost command can be used to maintain a
host-based access control list, which is probably sufficient for a workstation (single user) envi-
ronment. However if a multiuser host/X-terminal environment one of the user-based authenti-
cation mechanisms should be used.
Autolock Screen
Insisting users logout every time they leave their workstation will meet more opposition from
windows users than tty users. It takes too long to start/stop windows and besides they might
want to leave something running. Rather than rely on users discipline to run “lockscreen” some
administrators mandate that an automatic lock screen program (such as xlocktool) be run in the
background. This will help deter opportunists, but may actually assist serious hackers to obtain
passwords!
The problem being that a user can be given a false sense of security by xlocktool. The first thing
the user will do on return to his workstation is type his password to what he assumes is the
xlocktool program. As he did not personally invoke the lockscreen program he has no proof
that he is not giving his password to a trojan mule program left running by a hacker. (See section
15.2) It is therefore always better to lock your workstation manually.

!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 22
7.9 Loading files from Media
“Every floppy and tape drive on you network is a potential security hole! “
With distributed systems a tape drive can be connected to any workstation and files loaded onto
the servers from there. Most SPARCstations have a floppy drive as standard. It might be justi-
fiable to stipulate that no client systems with floppy/tape drives should be connect to your net-
work.
Although not supported, a “lunch-box” tape could be plugged into a Solaris1 workstation and
used immediately as all SPARCstations have an external SCSI connector. With Solaris2 only
the root user can do this. Solaris2 requires a reboot with the “-r” option before the tape will be
recognised and a /dev/rmt device file created. Provided the EEPROM is setup correctly only
root can do a “boot -r”. It is possible to use the “tapes” to create /dev/rmt files attach new tapes
but this also has to be done as root.
Tape Archive command “tar”
When new software packages are bought, how often does the installation instruction tell you to
“su” to root then extract the files onto your machine using the “tar” command? This is very dan-
gerous as tar will overwrite existing files with new ones. You could inadvertently load tampered
versions of key system commands such as /usr/bin/login. It is always a good idea to list the con-
tents of a tape before loading it. The files and directories on the tape should never contain ex-
plicit path names like “/usr/bin/prog”. Look out for hidden directories. If the suggested tar
command includes the “p” option be even more suspicious, as files will be loaded with pre-de-
fined permissions ignoring your umask setting. The “w” option is useful as it will stop and ask
you if you really want to over write an existing file.
good# tar -xvwf /dev/rmt/0 bad# tar -xvfp /dev/rmt/0
x apps/bin/su x /usr/bin/newprog
x ./apps/bin/startup x /usr/bin/newprog
It is unlikely that an official release of popular application will contain any hacking tools, if it
comes shrink wrapped from the supplier. Its the less well known application or data file that

arrives on a reused tape that presents the question; or indeed an unofficial patch sent to you on
an unlabelled floppy.
Volume Manager “Vold”
Only root can mount a floppy disk under Solaris1. Solaris 2 has improved functionality with the
Volume Management Software. When a floppy disk is inserted into the SPARCstations drive,
the volume management daemon will automatically mounts it, providing it contains a UNIX or
DOS file system.
It is still true that only root can mount/unmount disks. Which devices users can mount and with
what options is defined in the /etc/vold.conf file. This should only have write access by root.
The volume manager daemon ‘vold’ mounts everything “nosuid” in case the floppy contains
any setuid programs.
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 23
7.10 Device Allocation
A traditional problem with sharing tape devices is one of gaining exclusive use. Not just while
the tape is being used, but from the moment the tape is loaded until the tape is removed.
If the tape drive is physically remote from the user’s workstation there may be a considerable
time between the user placing the tape in the drive and walking back to his desk. During this
time a second user could read the tape or much worse write to the tape.
If the assailant can write to the tape he can place any program he likes on it, knowing that when
the legitimate user returns to his desk he will unwittingly load it. This is a good way for a hacker
to get his toolkit installed as root!
It is therefore good policy to physically make tapes read only with their protection tabs before
inserting them into the drive. Also a good policy to prevent accidental overwriting.
Solaris 2.3 has a mechanism to guard against this danger. It has two user commands, ‘allocate’
and ‘deallocate’. These are part of the BSM package. (See Section 14.1 BSM). Users can now
reserve a tape drive for their exclusive use before he loads the tape until after it is ejected.
Device allocation works by removing world read/write access permissions to the tape device
files. When a user request the use of a tape, ‘allocate’ check that no one else is using it. If the

tape is free ‘allocate’ makes the user owner of the device file. e.g.:
guzzi%whoami
chris
s -lg /devices/sbus@1,f8000000/esp@0,800000/st@4,0:
c 1 bin bin 18, 4 May 12 12.14 st@4,0:
guzzi% allocate st0
ls -lg /devices/sbus@1,f8000000/esp@0,800000/st@4,0:
crw 1 chris staff 18, 4 May 12 12.14 st@4,0:
Thus the user has private use of the tape between issuing the allocate and deallocate commands.
The deallocate command will run a ‘device cleaning script’. In the case of a floppy disk is will
eject it. In the case of a tape a custom cleaning scripts needs to be written which will prompt
the user with:
“Have you removed the tape from the drive (Y/N)":
Device allocation is needed for a system to qualify for the TCSEC C2 security rating (See Sec-
tion 14.1 History Of Solaris Security Products)
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 24
8.0 Network Security
Previously, I have stated that a computer is only as secure as the room it is locked in. I should
have continued to say as long as it’s not connected to a network. Providing you make the as-
sumption that your staff are trusted (dangerous to assume). Then all your security worries can
be ended by detaching the wide area network (WAN) communications links!
A corporation’s computers are most useful when connected to each other. If the organisation
has it’s own private network with its own dedicated cables then preventing espionage is just a
matter of securing access to those cables.Wire cables will emit radiation which can be interpret-
ed by clever receivers. Cables should be shielded but this is not practical over large distances.
In this respect optical cables are more secure.
8.1 Machine cloning
If the cabling is routed through hostile territory the problem is magnified as connections may
be tampered with. A system could be connected and made to impersonate a valid system by as-

suming its address and hostname. Admittedly the real owner of the address would have to be
silenced. However the rogue machine could be setup to forward on what it receives leaving the
real recipient none the wiser. This is a real threat nowadays where portable systems are capable
of network connection.
Most people think that a system can be uniquely identified by its ethernet address, assuming
that the ethernet address is etched into the ethernet chip. Few people realise that it is possible
to change an ethernet address using (ifconfig le0 ether x:x:x:x:x:x). So it is possible to com-
pletely clone any system with another machine of its type.
8.2 Network Snooping
In the case of ethernet, any system connected to the network can eavesdrop on other systems’
conversations. This is known as “snooping”. If it’s a remote login conversation then the pass-
word will be visible. All ethernet controllers read every passing packet to find out whether it is
for them. Normally if the packet is not for their address it is discarded. However the ethernet
driver can be put into “promiscuous mode” where it interprets every packet. Eavesdropping
programs take advantage of this promiscuous mode. Solaris 2 comes with such a program “/usr/
sbin/snoop”. Snoop is intended to help debug network problems but is a potential security risk.
Anyone can execute it but read permission is needed on /dev/le making this an important device
to monitor.
Snoop has many features that allow only certain type of packet to be reported. Snoop makes
very effective use of the network packet filter and the streams buffer to efficiently and discern-
ingly capture the required packets. The output from snoop could simply be searched using
“grep” for the string “password” or “login”.
Snoop was not included in Solaris1 but could be obtained from the internet. SunSoft has been
unfairly criticized for including snoop in Solaris2. Other vendors have similar standard utilities
- they are just not called “Snoop”. You need to be root to run snoop, which is another reason to
deny workstation users their root passwords. (Note: Solaris1’s ‘etherfind’ command has snoop-
ing potential).
!
Solaris Security : A Practical Guide : Revision 1 Chris Tomlinson SunUK
Page 25

9 Network Authentication
Because of the potential for “snooping” it is not wise to trust even local area networks (LANS)
and make sure that no unencrypted password information is transmitted. This present a new
technical problem. It’s no good sending encrypted information to a system without first sending
it a key to decrypt it with. In which case how do you send the key without others seeing it?
9.1 Secure RPC
Remote procedure calls (RPC) are a common facility used by network applications. By setting
up the DES system as described below, LANs can be made secure. It is possible that some ap-
plications will run secure RPCs while others use standard RPCs. Applications that can use se-
cure RPCs include NFS, Admintool and NIS+. Solaris 2‘s RPC library can be used with several
authentication flavours:
AUTH_NONE - No authentication
AUTH_SYS - Normal UNIX netid based (default)
AUTH_DES - Uses DES authentication
AUTH_KERB - Uses kerberos authentication.
DES encryption is used in both DES Authentication and Kerberos Authentication. Note: The
DES is used to describe both an encryption system as well as an authentication mechanism.
9.2 DES Authentication
DES authentication uses the Data Encryption Standard (DES) and public key cryptography to
authenticate both users and systems. Essentially, credentials are exchanged in an encrypted for-
mat. In order for the server to decrypt these credentials it needs to have the correct key. The
client cannot just send the key as the true identify of the server has not been established, also
others might see it (see section 8.2 Network Snooping)
Public key cryptography is a mechanism by which client and server obtain a common key
known as the “conversation key”. Both machines have a public key and a private key. A ma-
chines public key is known by everyone however private keys are only known by their owners.
The server deduces the conversation key by combining the clients public key with it own secret
key and vice-versa. A client machine sets up it’s public and private key by using the “keylogin”
command as root. A user normally does a keylogin transparently as part of the login process.
Key Server daemon

In order that the conversation key does not have to be continually calculated the server stores
the conversation key and gives it an index. This index and a time stamp is encrypted by the con-
versation key and sent back to the client. The client only needs to send the index and an encrypt-
ed time stamp for future credentials verification. Programs access users netname, public and
secret key through the” keyserv” daemon. The secret key is DES encrypted with the users pass-
word. Keyserv stores these in the /etc/publickey file. Users can change theses keys with the
“chkey” command. The encrypted secret key must be kept in sync with the users password. The
passwd command will do this automatically.
!