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

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

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

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

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

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.

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-

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-

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

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-

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.

% 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-

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.

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

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

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.
!