Digital PDFs

AA-PBKQA-TE

May 1990

92 pages

Original

4.5MB

view download

OCR Version

3.9MB

view download

Document:	ULTRIX Security Guide for Users
Order Number:	AA-PBKQA-TE
Revision:	0
Pages:	92
Original Filename:

OCR Text

ULTRIX

Security Guide for Users

Order Number: AA-PBKQA-TE
June, 1990

Product:

ULTRIX Version 4.0 or higher

digital equipment corporation
maynard, massachusetts

Restricted Rights: Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in
subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause of DFARS 252.227-7013.

The information in this document is subject to change without notice and should not be construed as a commitment
by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may
appear in this document.

The software described in this document is furnished under a license and may be used or copied only in accordance
with the terms of such license.

No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital or its
affiliated companies.

The following are trademarks of Digital Equipment Corporation:

flnflnan

DECUS

ULTRIX Worksystem Software

DECwindows

VAX

CDA
DDIF

DTIF
MASSBUS

VAXstation
VMS

DDIS

MicroVAX

VMS/ULTRIX Connection

DEC

Q-bus

DECnet

ULTRIX

XUI

DECstation

ULTRIX Mail Connection

Network File System and NFS are trademarks of Sun Microsystems, Inc.

UNIX is a registered trademark of AT&T in the USA and other countries.
X Window System, X, and X11 are registered trademarks of MIT.

Contents

About This Manual
AUGIENCE

oott
e e,
t

OFaNIZALION

.....cuuiiiiii
it iiiieii
ee e e
ae eiiitiie
e e ee e e e e e e eeeeeseeese s

Related DOCUIMENTS

CONVENTIONS

¢eeeieieieie
e ettt e eieieti
e e e e e e e e eeeeeeee e e e
ieeeeeee

Understanding Your Role in Maintaining Security

1.1

What Is Computer Security?

1.2

Threats to Information SECUTILY
1.2.1

Masquerade Programs

1.2.2

Trojan Horse Programs

........cuuvveeeeiiiiiii
e eeeeeeeeeeeeeeeeens
iiiiereeveees

1-1

.......eeeveeiiiiiiiiiieeeeeeieeeeeeeeeeeeeeeeeeeeeeeee,

1-2

.......ccccccevveiiiiieierrieiiieeceeesieeeeeeeeeeeeeeeeeeeeae

1-2

..............ocoovviiiiiiiiimiieeeeeeeeeeeeeeeeeeeereeeeeeeneens

1-3

1.3

Overview of ULTRIX Security FEAtures

1.4

User and Security Administrator Security ROIES
LAl

USET

142

Security AAMINISITAIOr

..........ccooeeevemeemeeiieeeeeeeeeeeseeeeeeesasanns
.......eeeeevveeereeeveeverseeeeesaennn,

2.1

How the System Knows WHho YOU ATE€

2.2

LogEING IN

...oooiviiriemeieieeeeeeeeeeeeeeeeeeeeeeeseenens

2-1

2-2

2.2.1

Invoking a Trusted Path

2.2.2

Checking Login MESSAZES

223

Understanding Login AUditing

...ttt

2-2

..ccceveeeeiiiiiiiiiiiiiiiineeeeeeeeeeeeeee
e eeeeeeens

2-3

...........coovmuieiiiereeieeieeeieeeeeeeeeseerennnns

2-3

PaSSWOIAS ooiiiiiiiiiiiiiiiiieeitie ettt e e e e eee e e e e e

2.3.4

oeeeeeeeeieeeeeeeeiieieieeieeeeeeeeeeeeeeeeeeeeeeeeeee
e eanas

Protecting Your Account

2.3.3

1-3

ett
et et e e e e e e et
ee e e e et aeer e s

2.3.1
2.3.2

..oeue
ettt
niiiei
ee e e oo
iiiiii
e e,
iee

2.3

rnnns

2-3

'Where Passwords Are Stored .......ccceeeeveeiiiiiieiiiieeeeeeeeeeeeaaeaeaens
Maximum and Minimum Password Lifetimes
...........ccccovevevvvvevmerennnnns

2-4
2-4

.........eeeeveiiiiiiiiieeerieeeeeeeeeeeaaeeenens
..........cecveeiiiiiiiiii
e
eeeeeaaaaaaans
iiii

2-5

Keeping Your Password SECTEt

Avoiding Bad Passwords

2-5

2.3.5
2.3.6
2.3.7

e
Choosing Good Passwords .........cocceviiiiiiiiiiriiiiiin
Using System-Generated Passwords — .........cooeiiiiiiiiniiiniiiniiininnaen,
Dealing with Expired Passwords .......ccccocoeivimiiiiiiiiiniiiiiiiinees

2-5
2-6
2-6

2-7

iiiiii
et
iiiiiii
et
.oooiii

2-7

e teaseeseans
..c.oeuvviiruiiiiuiiiiiimiiiieeeiiieesiieeerrinseaieeretaseeeeanes

2-8

........coccoiiiiiiiiiiiiiiiiiiiiiii

2.4

Leaving Your Terminal

2.5

Log@ING OUL

2.6

SeCUrity SUMIMATY

Protecting Your Files and Directories

3.1

File Types, Ownership, and the Is -Ig Command
3.1.1
3.1.2
3.1.3

...,

3-1

File TYPES corereeiieeiieeii ittt
et e e et s e e
File OWRErship ceeeveeuieriniiiiiiiiiii
e e
........ccooviriniiiimiiimiiiiiiriie et
Thels -lg Command

3-1
3-2
3-2

........ccooiimiiiimiiiniiiiiiniineenee.

3-3

Using Octal Numbers and Symbolic Values for File Permissions —.........
Setting Your File Creation Mask with the umask Command ................
Changing File Permissions with the chmod Command ..............c.........
File Permission Command SUummary ........cccceieviieiieeinniiiniiienincienees,
File Permission Reference Table .......ccccooviiiiiiiiiiiiiiiiiiinn.

3-3
3-5
3-6
3-7
3-8

.......o..ocoooeiiiiiiiiiiiie,

3-8

Changing the Group Associated with a File ........cccoocooiiii.
Using Directories to Increase Security ..........coeeiiiiiiniiinniiniiiinnn

3-8
3-10

................

3-10

.........ccooeviiiiiriiiiniinnnnnnne.

3-11

...........cc..ceoceeeeeie.

3-13

...,

3-14

ireeeeete
e e e e s sernee e e eeeeraieeeseraaaaes
..ceooemuriiiiiimmiiiiiiiiiiii

3-15

Maintaining Restrictive File Permissions

3.2

3.2.1
3.2.2
3.2.3
3.2.4
3.2.5

Using Groups and Directories to Control Access to Files

3.3

3.3.1
3.3.2

3.4

Checking File Permissions and Ownership with the find Command

3.5

How File Permissions Affect Command Execution

3.6

How File-Manipulation Commands Affect File Permissions

3.7

Using Encryption to Protect the Contents of a File

3.8

Security SUIMMATY

Processes and Shells

4.1

WHhat IS @ ProCeSsS?

4.2

Real and Effective UIDs and GIDS ..c.coveniniiniiiiiiiii

4.3

SUID and SGID Programs

iiiiiii
ittt et s e s st srsrsasaaeeaeaseasees
ceeiiiiiieniiiieeineiiii

4-1

4-3

........ccceeveiiiniiiuiiiiiinnieiineiieieeeiesiessensenaseeasssasses

4-5

4.3.1
4.3.2
4.3.3

Example of an SUID Program ........cccciieriiimiiiniiiiniiiienneienienne,
Example of an SGID Program ...........oiomiiiiiiiniiiiii
Copying and Moving SUID and SGID Programs ..........cccccoeeeennniinnnn.

4-6
4-7
4-8

(=Y |

PP
U UTSUUUCUP U
U

4-9

iv Contents

4.4.1
442
4.4.3
4.5

Supported Shells
.....coviiiiiiiiiiiiiiii
s
Creating Secure Shell Startup Files
........ccoooiiiiiiiiiiiiiin,
Shell SCIIPS
.eveeeinniiiiiiiiiiiiiiii
e sa e s e e e e e

SECUTity SUMMATY

ce.oieuniiiiriiiiiiiiiiiiaiiirii
et ettt erie e e eeatee e stes st saaaas

Connecting to Other Systems
5.1

.......coooiiiiiiiiiiii
s

5-1

The /etc/hosts.equiv File .....coooiiiiiiiiiiiiiiiiiiiiii
e
The qhosts File ..coiniiiniiiiiiiii
e

5-2

The rlogin, rcp, and rsh Commands

5.1.1
5.1.2

5-2

5.2

The ftp Command ......cccoeieiiiiiiiiiiiiiii

5-3

The tftp Command ....cccoooiuiiiiiiiiiiiii

Local Area Transport (LAT) Commands

........cccoeviiiiiiiiiiiiiiiiniinieiieeenanens

5-4

5.5

The Uucp ULIILY

.oovvriniiiiiiiiiiiin
e e ee e e ee

The uucp cOMMANd
.......ceiivuiiininiiniiiiiiiiiri
et e e
The tip and cu Commands
.......cceeeevuiiiniiimiiiiiieii
s

5-5

5.6

The dlogin, dls, and dcp Commands — .......c.ovivuiiiiiiiiiiiiiiiriie
e,

5-6

5.7

SeCUrity SUMMATY

5-6

5.5.1
5.52

...ccevieeuiiiimiimiiiiiiiiieier
et ereineeeteeretastneeeiesesseesoseens

5-5

Workstation and Windowing Environments
6.1

Who Can Access Your Workstation Display?

......cccooiiiiiiiini

6-1

6.2

Controlling Network Access to Your Workstation — .........ccooeieiiiiieiiiiniinna..

6-1

6.2.1
6.2.2

6-2
6-2

6.3

Protecting Keyboard INput .......ccoeiiiiiiiiiiiiiiiiiiii

6.4

Blocking Keyboard and Mouse Information

6.5

Locking your WOIKSIatiON

6.6

PhySical SECUTILY

teeeuueeiiiuniiiiimiiiminiiiiiii
it
ee e e e et e e e te e tesesreaesennaeeens

6.7

SECUrItY SUMMATY

..oeeevniiiniiiiniiiiiiiiiiiiiii
et eerreerretteesrerseieetaeeeanseeaesrnassses

............ceeviiiiiiiiiiiniiiiiinnnin.

.....ccevviuiiiniimiiiiimiieiiririiireseerierneteceennseeeseneenses

6-3

AR AN

The System Access Control List
......coouiimiiiiiiieiiiiiiiiieee.
The Workstation Access Control 15 1
OOt

Contents v

Glossary

Security Summaries

B.1

Protecting YOUI ACCOUNE

B.2

Protecting Your Files and Dir€Ctories

B.3

Processes and Shells

B.4

Connecting to Other SYSIEMS

B.5

Workstation and Windowing Environments

...oeiiiriiiiiiiernieeeieiiiteeeeeeeraeeeeeeearaneseeeeanseeeennnnns

B-1

...........ceeeeriiviimeeieiiivineeeeneeeenennns

B-1

.....oooouiiiiiiiiiiiiiiiieiee
e
ee

B-2

.......iiiiiiiiiiieieiiieeeeeeeee
e e et

B-2

..............cccceeeeviiiviinnieeeneneeeeennnnnns

B-3

...........cccoeeveivuieeiiinnineeennnnene. ereereraeeans

Examples
3-1:

Octal and Symbolic File Permissions

3-2: How the File Creation Mask Determines File Permissions

.........cccccoeveuueeeeeenn.

3-5

3-3: Setting Absolute Permissions with the chmod Command

.........coccoevvvvuneeneenn...

3-6

3-4:

............cceuuevevennnnnnn....

3-7

........ccoeeveeveivivnnenennnnen.

3-7

Setting Relative Permissions with the chmod Command

3-5: Interaction Between the umask and chmod Commands

3-6: Using the groups Command

.........cceeeieriiiiiiiiiieeiee et

3-9

..........cceeeiieiiiiiiieiiiieeieneeeeneeenenennns

3-9

3-9: File ENCIYPHON

..oiiiiiiiiiiiiiiiiiee
et
et eeee et
e e e e e e e e eneeeeeeenen

3-14

3-10: File DECTYPLON

..oieiiiiiiiiiiiiiiee
e ee
et
eee
e
e e st e e e e e

3-15

3-7: Using the chgrp Command on a File .........coooeviiiiiiiiiiiiiiiii
3-8:

Using the chgrp Command on a DireCtory

4-1: Using the ps Command

.......c.uuvveieriiiiiiiiiiiieieeeieeeeeeeeeeeee
e
e eeeeene

4-3

Figures
4-1:

Parent and Child PrOCESSES

4-2:

GIDs and the Group Access LISt

ECHINT

11D (47:
) 1+

4-2

..c..ceieivieieiriiieeeeiiieeieiieeeeiieeeeeee
e eeranene

4-6

4-4: SUID and SGID Programs

vi Contents

.....ccvuueniieiiiiieiieiiiiiiee
e
e ee e

........cceeeueeiiiiuniiiiiiieieiiee
et eeeeeeee e e eeenns

4-8

Tables
3-1: Octal Numbers and Symbolic Values
3-2: Examples of umask Values

......ccccvviiiniiiiiiiiiiiiiiiiiiccee,

.........cccocoeiiuiiiiiiiiiiniiniiniii

3-6

....ccoceeiiiniiniininiiieiriiiiiiniiieiieieneeneennes

3-7

........c..ccooviviiiiiiiiiniiiiiinneereeaen

3-8

3-3: File Permission Command SUMMATIY
34: File Permission Reference Table

3-5: File Permissions Required for Successful Command Execution

.........c.............

3-11

3-6: File Permissions Affected by Successful Command Execution

.........cccceeeene..

3-13

Contents vii

About This Manual

The Security Guide for Users describes the security features available in the
ULTRIX-32 operating system. Some of these security features may not be available
at a particular site. Whether or not a security feature is available at your site depends
upon how your site has configured the ULTRIX environment to meet its security
needs.

Audience
This manual is intended for users who have some experience in an ULTRIX
environment. Users should understand basic ULTRIX commands, know how to set
file permissions, and understand basic shell syntax.

The Security Guide for Users describes security concepts whose understanding is
needed to help create a secure computing environment. The guide often provides
examples of ways to implement security concepts. However, the guide is not
intended as a tutorial for beginning ULTRIX users. Readers should be familiar with
the material in The Little Gray Book: An ULTRIX Primer, and be able to apply
security concepts in their own environments.

This guide is not intended for users who program. Users who need general
guidelines for writing secure programs in the ULTRIX environment should read the
ULTRIX Languages and Programming Guide.

Organization
The ULTRIX Security Guide for Users has six chapters, a glossary, a security
summary, and an index.

Chapter 1

Understanding Your Role in Maintaining Security
Introduces the notion of computer security, describes some common
security threats, and describes the roles that general users and the
security administrator play in maintaining system security.

Chapter 2

Protecting Your Account

Shows how the system verifies your identity and how you can check
for recent logins to your account. Tells how you can protect your

account by logging in through a trusted path, and which login
messages should be reported to your security administrator.
Provides ideas for creating secure passwords. Explains how to
leave your terminal or workstation during the day and how to log
out when leaving.

Chapter 3

Protecting Your Files and Directories
Provides a brief description of ULTRIX file-protection mechanisms

and reviews how you can set permissions for your files. Describes
the interaction between some system commands and file

permissions.
Chapter 4

Processes and Shells
Defines a process and discusses the difference between real and
effective user IDs (UIDs) and group IDs (GIDs). Shows how

SUID/SGID (set UID and set GID) programs affect the privileges
accorded a process. Discusses how to create a secure environment

for the login shell process.
Chapter 5

Connecting to Other Systems
Discusses the security concerns for commands that log in to,
execute commands on, and copy files from remote systems.

Chapter 6

Workstations and Windowing Environments
Provides an overview of the special security concerns inherent in
workstation and windowing environments.

Appendix A

Glossary
Defines ULTRIX security terms.

Appendix B

Security Summaries
Gathers together the security summaries from Chapters 2 through 6.

Related Documents
DECnet-ULTRIX User’s and Programmer’s Guide
DECwindows User’s Guide

The Little Gray Book: An ULTRIX Primer
ULTRIX Guide to System Environment Setup

ULTRIX Languages and Programming Guide
ULTRIX Reference Pages

ULTRIX Security Guide for Administrators

Xx About This Manual

Conventions
The following conventions are used in this manual:

hostname>

The default user prompt is your system name followed by a right
angle bracket. In this manual, a percent sign (%) is used to
represent this prompt.

A number sign is the default superuser prompt.

UPPERCASE

The ULTRIX system differentiates between lowercase and
uppercase characters. Literal strings that appear in text,

lowercase

examples, syntax descriptions, and function definitions must be
typed exactly as shown.

In text, bold type is used to introduce new terms.

macro

user

input

This bold typeface is used in interactive examples to indicate

typed user input.
system output This typeface is used in interactive examples to indicate system
output and also in code examples and other screen displays. In
text, this typeface is used to indicate the exact name of a
command, option, partition, pathname, directory, or file.

rlogin

In syntax descriptions and function definitions, this typeface is
used to indicate terms that you must type exactly as shown.

filename

In examples, syntax descriptions, and function definitions, italics
are used to indicate variable values; and in text, to give references
to other documents.

[]

In syntax descriptions and function definitions, brackets indicate
items that are optional.

cat(l)

Cross-references to the ULTRIX Reference Pages include the
appropriate section number in parentheses. For example, a
reference to cat(1) indicates that you can find the material on the
cat command in Section 1 of the reference pages.

CTRL/x

This symbol is used in examples to indicate that you must hold
down the CTRL key while pressing the key x that follows the
slash. When you use this key combination, the system sometimes
echoes the resulting character, using a circumflex (/) to represent
the CTRL key (for example, AC for CTRL/C). Sometimes the
sequence 1s not echoed.

RETURN

This symbol is used in examples to indicate that you must press
the named key on the keyboard.

About This Manual xi

Understanding Your Role in Maintaining

Security

This chapter provides a brief introduction to the importance of computer security. It
discusses the roles that users and security administrators play in creating and
maintaining a reasonable level of security in an ULTRIX computing environment.

Access to information in computer systems is a balance between openness and
secrecy. On one hand, users need to share information with relative ease. On the
other hand, security administrators and users must guard against having information
copied or removed by unauthorized personnel. Neither the operating system nor the
security administrator can stop you from giving away information that you own.
However, you should be aware of the security tools at your disposal and the risks
engendered if you use them improperly.

As you read this guide, remember that computer security is not a static discipline;
each major technological advance in computing seems to spawn a new set of security
issues. Designing secure computers is an evolving discipline. Although some

security standards exist (for example, the Department of Defense Trusted Computer
System Evaluation Criteria, DoD 5200.28-STD, December 1985), the tools and
techniques employed by those who design computers and those who try to break into
them are constantly changing.

1.1

What Is Computer Security?
When you leave home, you lock the doors to decrease the chances that someone

might break in and destroy or steal your possessions. You could install burglar
alarms, balancing the inconvenience of using these security devices against any
potential loss.

In a computing environment, maintaining security is more difficult. For example, you

may not know that someone has broken into your account; if someone copies your
files, nothing is missing, but the information is no longer secret. Locking the doors
does not guarantee that the information is safe.
When discussing computer security, two terms are frequently used: physical security
and information security.

Physical security is protecting the computer itself from physical attack; for
example, locking a computer room to prevent the theft or destruction of
hardware or backup tapes provides a measure of physical security.

Information security is protecting the programs and information contained
within the computer from attack; for example, setting restrictive file protections

on a sensitive file provides a measure of information security.
Before networks and modems were commonplace, physical security provided a
degree of information security. Although physical security will always be a security
consideration, it no longer provides adequate information security. When a computer
is connected to a network or a modem, security risks increase exponentially because
an attacker no longer needs physical access to the computer, or to any terminals

connected directly to it. Probably the only truly secure computer is a single-user,
fault-tolerant system locked in a bank vault with no network or phone access — and
N0 POWer.

The emphasis in this guide is on information security because the security features
available to users in the ULTRIX operating system help protect information.
Information security has four aspects: secrecy, integrity, availability, and
accountability.

1.2

Secrecy is protecting information from unauthorized disclosure. Passwordprotected accounts allow only valid users to log in to a system. File permissions
limit the rights of other users to read your files.

Integrity is protecting information from unauthorized modification. File
permissions limit the rights of other users to modify or delete your files.

Availability is protecting the system from denial-of-service attacks that range
from misusing system resources to crashing the system. Your security
administrator has programs to monitor system resource use.

Accountability is identifying and holding a user accountable for actions that
create, modify, provide access to, or disseminate information. Your security
administrator has programs capable of tracking the actions of an individual user.

Threats to Information Security
Information security for ULTRIX systems depends on the notion of the authorized
user; anyone who knows the user name and password for an account can log in and
be granted all the privileges associated with that account. For this reason, an attacker
will often try to gain access to a user account, with the goal of eventually gaining
access to the root account and its superuser privileges.
Two common techniques used by attackers to steal information are the masquerade
and Trojan horse programs. These two techniques represent deliberate attempts by
other users or attackers to breach security.
A more pervasive but less spectacular threat is an authorized user who does not
employ available security features to protect accounts and files adequately. This is
akin to protecting your house by nailing the doors shut and leaving the windows
open. In other words, the best security features in the world are worthless if not used.

1.2.1

Masquerade Programs
A masquerade program pretends to be a legitimate part of the operating system.
This program then attempts to fool you into revealing sensitive information.
A common masquerading technique is a program called a password grabber. This
program runs at an unattended terminal and waits for a user to attempt a login.
Masquerading as the system’s login process, the program prompts for a user name
and password, which it steals and copies to a location specified by the attacker. After
stealing the user name and password, the program displays a false error message and
returns control to the real operating system. If you are caught by this type of
program, you will probably assume that you have incorrectly entered your password,
not knowing that you have just given it away.

1—2 Understanding Your Role in Maintaining Security

1.2.2

Trojan Horse Programs
A Trojan horse program gains access to sensitive information by pretending to

serve a valid purpose, while concealing its real intent. Almost any program can be
turned into a Trojan horse by inserting a hidden subprogram into it. While the

program performs its advertised function, the subprogram takes advantage of the
user’s privileges to copy, modify, or execute any files that the user can access.

For example, a Trojan horse could be concealed in a spelling-checker program.
While the program checks your spelling, it secretly copies files from your account to

the attacker’s account or to a public account.

Note
The success of the masquerade and Trojan horse techniques depends on
the attacker’s ability to plant or modify a program on your system. An
attacker does not need to gain access to a user account if a user copies a

program of this type into an account and runs it. For this reason, never

copy a file to your system and execute it unless you know what is in it.

1.3

Overview of ULTRIX Security Features
The ULTRIX system is a multitasking, multiuser system. It can perform more than

one task at a time and share resources among many users. Precisely because it is a
multiuser system, it has to perform a number of tasks that directly or indirectly affect

security. The following list describes some of these tasks:
*

The system maintains separate user accounts, checking user names and
passwords at login and putting users in the correct accounts. This ensures that
only authorized users can log in, which affects information secrecy, integrity,

and availability.

The system assigns each user a process at login time, keeps track of any

processes created by this process, and ensures that resources allocated to any
process are available for the life of the process. The system also records all

The system checks ownership and permissions each time a process attempts to

access a file to ensure that the process has permission to read, write, or execute
the file. This file-access control provides information secrecy and integrity.

On an ULTRIX system, users assign permissions to their files and control, to a large
extent, the security of their accounts. This provides both freedom and flexibility, but

demands that users behave in a responsible manner and provide the degree of security
required by their environment. The following analogy may help clarify some system

security issues.

Your user account on an ULTRIX system is similar to that of a tenant’s

apartment in an apartment building. The front entrance to the building is
controlled by the landlord who passes out keys to tenants. You can

decorate your own apartment. You can also give other tenants permission
to look at, change, and play with any of your possessions. However, you
cannot look in other tenants’ apartments without permission.

The landlord’s apartment has a lot of expensive furniture, plus the keys

for all the other apartments. Usually you are allowed to look around this
apartment and play with certain items; however, this is entirely at the

Understanding Your Role in Maintaining Security 1-3

discretion of the landlord. You are not allowed to remove or change
anything important in the landlord’s apartment.

If a burglar breaks into your apartment, the following might happen:

Your possessions can be stolen or ruined (mv or rm commands ).

The burglar can find out who else has apartments (by looking at the

A cunning burglar might take pictures of (cp) your secrets, hide a spy
camera (perhaps some type of Trojan horse), and leave without a trace.

The burglar may be able to break into the landlord’s apartment and put the

/etc/passwd file ).

whole building at risk by getting the keys to all the other apartments.

The risks are even greater if the burglar is one of the tenants.

1.4

User and Security Administrator Security Roles
Users often greet security measures with disdain, assuming that most security
measures are restrictive, annoying, and a waste of their time. Oftentimes this is
because users do not understand the risks involved in using computers as a tool for
creating, storing, and sharing sensitive information. Because the ULTRIX system
gives users some control over the security of their accounts, both users and security
administrators share responsibility for watching over the system.

1.4.1

User

Users must protect their accounts and files. As a user, you should know the system
well enough to take reasonable precautions when performing an operation that could
affect security. You should report any signs of a security breach to your security
administrator. For example, if you know you have typed your password correctly, but
your login attempt fails.

1.4.2

Security Administrator

The security administrator implements security policy by controlling logins and
access to system-level files and services. The security administrator is responsible for
auditing the system to check for security breaches. On a well-managed system, the
security administrator makes sure that users understand the security policy and the
reasons behind it. The security administrator might also be responsible for the
physical security of the equipment and the configuration of certain aspects of the file
system that have security implications.

Note

On many systems, the system manager also acts as the security
administrator. However, because the role of security administrator differs
from that of system manager, this guide refers to the person responsible
for security matters as the security administrator.

The following chapters explore ULTRIX security issues and provide the information
you need to make rational decisions about security in your own account.

1—4 Understanding Your Role in Maintaining Security

Protecting Your Account

To a large extent, security in an ULTRIX environment depends on denying an

attacker entry to a system. Once in a system, the odds favor an attacker because even
extremely restrictive file permissions offer no protection if the attacker becomes the
owner of the files. Therefore, protecting your account is your first line of defense.

This chapter describes:
*

How the system identifies authorized users and allows them to log in

How to invoke a trusted path for a secure login

®*

Which login messages and system files can help you determine if someone has

logged in to your account

2.1

®*

How to choose good passwords and protect them

®*

What to do when you leave your terminal

How to ensure that logout procedures have executed

How the System Knows Who You Are
The system knows who you are by your account entry in the /etc/passwd file.
Your entry has your login name, your password (if your security administrator is

storing it there), information about your account, and two numbers that identify you

to the system: your user ID (UID) and your group ID (GID). The system uses your

UID and GID to control your actions and your access to files. For more information
on /etc/passwd, see passwd(5) in the ULTRIX Reference Pages.

When you log in, the system prompts for your user name. It then prompts for your
password. Because only you should know your password, the system accepts the

correct entry of the password as valid proof that you are really you. Most systems
have users prove who they are only at login. Therefore, from the system’s point of

view, anyone who knows your user name and password is you.
Whenever someone attempts to log in, the system requires both user name and
password information before allowing or denying access. The system could be
programmed to display a login

incorrect message whenever someone entered

an invalid user name, and not prompt for a password. But if the system did not

display a password prompt when someone entered an invalid user name, an attacker
could use this information to distinguish between valid and invalid user names.
After the system verifies your identity at login, it creates a process for you and
assigns the UID and GID from your /etc/passwd entry to this process, along with
any additional GIDs from the /etc/group file. You have only one UID, but can
belong to more than one group. Groups are discussed in greater detail in Chapter 4.
For more information on /etc/group, see group(5) in the ULTRIX Reference

Pages.

Whenever you issue a command or run a program, the system starts a process for you
and assigns your UID and GIDs to that process. This enables the system to keep
track of what you are doing and to determine whether or not you can open a file or
execute a command. Each time you ask the system to perform an action, it checks
the rights associated with your process.

2.2

Logging In
This guide assumes that you know how to log in to your ULTRIX account. If you
do not, refer to The Little Gray Book: An ULTRIX Primer for an introduction to
ULTRIX systems.

Note

Because displays may differ for terminals and workstations, the messages
and system output shown in examples throughout this guide might not
match those displayed on your screen. However, the principles behind
the examples are similar. See Chapter 6 in this manual for an overview
of security concerns relating to workstation and windowing
environments.

2.2.1

Invoking a Trusted Path
When you log in from a hardwired or Local Area Transport (LAT) terminal, the
program displaying the first login: prompt is getty (). This program calls
login (), which displays the Password: prompt and continues the login
sequence.

A classic masquerade tactic is to steal user names and passwords by imitating the
getty () and login () programs. To defeat this tactic, the ULTRIX operating
system provides a trusted path to getty (). This trusted path ensures that you are
communicating with the real getty () program and not with a masquerade program.
When you invoke a trusted path, the system terminates all processes attached to your
terminal (thus terminating any masquerade program) and then starts getty (). This
ensures that your user name and password are passed only to the correct system
programs.

Your security administrator can tell you if the trusted path mechanism is enabled on
your system. If it is, the security administrator has defined a key that you must press
to invoke a trusted path. This key is called the Secure Attention Key (SAK).
Note

There is no ‘“SAK”’ key on your keyboard. The system administrator
defines one of the existing keys as the Secure Attention Key. If the
key is defined as your Secure Attention Key and your terminal
connects to a terminal server, there is a potential conflict. Most terminal
servers intercept a
keystroke and interpret it as a request to
display the terminal server prompt. In this case, your request for a trusted
path will always be intercepted and interpreted by the terminal server.
To resolve this conflict, simply change the terminal server attention key
to some other key. For example, to change the terminal server attention

key on a DECserver 200 from [BREAK] to [CTRL/A] type the following
at the LOCAL> prompt:
LOCAL> set port local CTRL/A

2-2 Protecting Your Account

2.2.2

Checking Login Messages
At login, pay attention to the messages that indicate both your last login time and any
recent login failures. For example:
login:

hale

password:

<not

Last

Fri

There

have

been

displayed>

May
0

07:26:53

unsuccessful

on ttyl7
login

attempts

your

account

If the last login time displayed is not the last time you logged in, tell your
security administrator.

If any reported login failures were not your own, tell your security

administrator.

Do not ignore any evidence that someone might have attempted to get into your
account.

2.2.3

Understanding Login Auditing
The system maintains a record of recent logins and logouts in /usr/adm/wtmp.

To display a list of recent logins for your account, use the 1ast command with your
user name as the argument. For example:
%

last

hale

ttylé

Mon May

07:39

hale

ttyl7

Fri

May

07:26

still
16:58

logged

(09:32)

hale

ttylé

Thu

May

07:23

12:14

(04:51)

hale

ttyl6

Wed May

07:36

16:57

(09:20)

hale

tty20

Tue May

09:32

16:53

(07:20)

hale

ttylé

Mon May

12:20

17:36

(05:16)

hale

ttyl?

Mon May

07:38

10:23

(02:44)

If you cannot remember any recorded logins, tell your security administrator. By

checking your login messages for failed login attempts and using the 1ast command
to check for unauthorized logins, you should be able to spot both failed and
successful attacker login attempts.
Your security administrator also keeps an eye on failed login attempts. The system
maintains records of failed logins in the /usr/spool/mqueue/syslog* files.

You have read access to these files. Five successive failed logins generate a warning
message in the current system log. This alerts your security administrator to a
possible attack.
In addition to tracking failed login attempts, your security administrator can record
all invocations of the login program. The security administrator can selectively
retrieve information and check for abnormal events. If there is a security breach, the
security administrator can reconstruct the details of the attack.

2.3

Passwords
Password security is one of the cornerstones of system security. Your security
administrator selects your first password when creating your account. Because
security risks increase whenever more than one person knows the password for an
account, always change your password immediately upon receiving a new account.

Protecting Your Account 2-3

When you change your password, the password you enter is encrypted and stored.
Whenever you log in and enter your password, your entry is encrypted and checked

against your stored password. If they match, you are allowed to log in.

Note
Encryption is the process of transforming data to an unintelligible form
in such a way that the original data either cannot be obtained (one-way
encryption) or cannot be obtained without using the inverse decryption
process (two-way encryption). The ULTRIX operating system uses one-

way encryption for passwords.

2.3.1

Where Passwords Are Stored
Historically, encrypted passwords and user account information are stored as entries
in the /etc/passwd file. Although root owns /etc/passwd, anyone on the
system can read this file. This generally presents no problem because the password is

encrypted. However, a sophisticated attacker could obtain a copy of /etc/passwd,
encrypt commonly used passwords, and look for matches to valid passwords.
The ULTRIX Version 4.0 operating system provides the option of storing encrypted

passwords in /etc/passwd or in a data base file called /etc/auth. Read and
write access to /etc/auth is restricted to root. Your security administrator
determines whether or not encrypted passwords are stored in /etc/passwd or in

/etc/auth.

2.3.2

Maximum and Minimum Password Lifetimes
If your password is stored in /etc/auth, your security administrator can increase
security by setting some limits on your password.

Setting a maximum and a minimum password lifetime.
A maximum lifetime forces you to change your password on a regular basis by
causing your password to expire after a specified length of time.

A minimum

lifetime specifies a length of time that you must keep a password before you can
change it. This helps you resist the temptation of changing to a new password

and then changing back to your old familiar one.

If your password has a maximum lifetime, the system displays a login message
starting five days before your password expires. The message tells you the
number of days remaining before your password is invalid. This reminds you
to change your password before it expires. To display your password expiration
date at any time, use the shexp command.
%

shexp

Expires

Tue

Dec

10:49:18

EST

1989

Setting a minimum password length.

When using /etc/auth, a password can be up to 16 characters in length.
Your security administrator can specify a minimum password length. This
increases security because the longer the password, the larger the pool of

possible choices, and the harder it is for an attacker to guess an individual
password.

2—4 Protecting Your Account

2.3.3

Keeping Your Password Secret
Protecting your account depends on choosing a good password, keeping it secret, and

changing it regularly. Use the following suggestions to keep your password secret:
e

Select a password that is hard to guess.

Make sure that no one is watching when you enter your password; some people
can remember keystrokes. Also, you could type your password when you meant
to type your user name; your password would be echoed on the screen.

Keep your password or passwords in your head, not in a file, on a piece of
paper, or mapped to a function key on an intelligent terminal. Do not include

your password in an electronic mail message.
*

Change your password regularly.

If you have more than one account, use a different password for each account.
Otherwise, an attacker who breaks into one account has a key that opens more
than one door.

2.3.4

Avoiding Bad Passwords
If you are allowed to choose your own passwords, avoid choosing ones that are easily
guessed. After reading the following list, you should be able to tell if your current
password or passwords offer much resistance to an attacker running a password

guessing program.
Do not use the following as passwords:

2.3.5

Your user name

Human and pet names

Words found in dictionaries and spell-checking programs

Street and city names

Well-known fictional characters and places

Any of the previous items spelled backwards

License plate and social security numbers

Passwords under six characters in length

Choosing Good Passwords
Good passwords take advantage of the variety of upper- and lower-case characters
available on the keyboard. You can use characters like the underscore (_) or square
bracket ([) to make your password more complex. For example, Try_this[1 is an
acceptable password.
Use the following suggestions when creating a password:
®*

Make sure that your passwords are six or more characters in length.

Use passphrases (passwords created by stringing words or pronounceable
syllables together; for example, nottoworry).

Create an acronym from an uncommon phrase (for example, the phrase ‘‘I want
to live in New Zealand’’ could become iw2liNZ).

Protecting Your Account 2-5

Use a mix of alphabetic and nonalphabetic characters (for example,
not.2.worry).

Use a mix of upper- and lower-case characters (for example, nOt2worry).

The best passwords combine several of these suggestions, as in the case of
nOt_2.woRry. However, do not create a password that i1s so complex you cannot
remember it.

2.3.6

Using System-Generated Passwords
On most systems, you can choose your own password. However, your security
administrator can specify that the passwd command display a list of acceptable
passwords. Each password is divided into syllables, which are separated by hyphens
to make it easier to pronounce and remember. This hyphenated form of the password
appears next to each password. If you do not like any of the passwords on the first
list displayed, you can display other lists of acceptable passwords. However, you do
not have the option of creating your own password.
If you have the option of choosing your own password, you can still have the system
provide a list of acceptable passwords by issuing the following command:
% passwd -a

Note that passwords generated by passwd meet the guidelines set forth in the
Department of Defense Password Management Guideline, CSC-STD-002-85.
Note

If your system uses Yellow Pages (YP), use the yppasswd command to
change your password.

2.3.7

Dealing with Expired Passwords
In addition to setting a maximum lifetime for your password, your security
administrator can set a soft expiration period for your account. This option gives
you one, and only one, chance to log in with an expired password.
If your account has a soft expiration period and you log in with an expired password,
the passwd command is automatically executed. You must change your password
before the login procedure will complete and put you in your home directory.

If you do not have a soft expiration period and your password expires, you will have
to ask your security administrator to create a new password so you can log in.
Workstations

If you use a workstation and your password is due to expire within the next five
days, the workstation displays a list of system-generated passwords. This list is
similar to the list you can generate with the passwd -a command. You can click on
the MORE button to display additional system-generated passwords.

You can type in your own new password, or you can choose one of the systemgenerated passwords.

2—6 Protecting Your Account

2.4

Leaving Your Terminal
Train yourself to take the following two steps whenever you leave your terminal, no
matter how short a time you plan to be away from it. (If you use a workstation, also
see Chapter 6.)

Return to a shell prompt (usually % or $) and enter the clear command to
clear the screen.

If you are connected to a terminal server that allows you to lock the port for
your terminal, you have two options:

Lock the terminal server port. Digital’s terminal servers such as the
DS100, DS200, DS300, DS500/500 and ETS support the 1ock command,
which prompts for a password and then locks the port. To unlock the port,
enter the password.

Lock your current ULTRIX session by typing lock at the shell prompt.
The system prompts you for a password and then locks the session. Note
that if you have other sessions that are not locked, anyone can use your
keyboard to access the terminal server and resume a session you forgot to

lock. To unlock the session, enter the password. For more information on
the 1ock command, see 1ock(1) in the ULTRIX Reference Pages.

Note
Because you deny access to any sessions connected to that port, locking
the port is the preferred method.

2.5

Logging Out
When you log out, make sure that you have really logged out. It is easy to press the
wrong keys when you are in a hurry, and leave a live session behind you. Most users
have at one time or another come to work to find a live session from the previous
day.

Also, if you have stopped jobs, the system might not log you out the first time you
try to log out. For example, the C shell displays the following message if you have
any stopped jobs and attempt to log out.
There

are

stopped

jobs.

You have the choice of checking on the jobs and then logging out or reissuing the
logout command. If you forget that you have stopped jobs in the background, you
might issue one logout command and walk away. You think you have logged out,
but the system is waiting for you to respond to its message.
If the terminal is in a public area, the security risk is increased. Take the time to
verify that you have indeed logged out of your current session by checking for a
logout verification message on your screen.

If your terminal is connected to a terminal server, verify that you have logged out of
all sessions connected to the port. Digital’s terminal servers such as the DS100,
DS200, DS300, DS500/500 and ETS support the show sessions command,
which lists any active sessions on the port.

Protecting Your Account 2-7

If you have responsibility for the physical security of your terminal or workstation,
make sure that any physical locks on the equipment or on the room containing the
equipment are securely locked before leaving.

2.6

Security Summary
Your account is your first line of defense:

If enabled on your system, use the Secure Attention Key to ensure that your
user name and password are passed only to the correct system programs at

Pay attention to login messages that contradict your memory of your last login
attempts. Use the 1ast command to check recent logins to your account.

Protect your password:

Pick a good one. Consider using a passphrase or a system-generated
password.
Keep it secret. Do not write it down. Do not let others see you type it.

Change it regularly.
Use different passwords for different accounts.
*

Lock your session whenever leaving your terminal during work hours.

Verify that you have terminated all sessions before leaving work.

2-8 Protecting Your Account

Protecting Your Files and Directories

This discussion of file and directory protection assumes that you have some

knowledge of ULTRIX file permissions, including the use of the chmod command

and the umask shell command. For a basic introduction to file permissions, refer to
The Little Gray Book: An ULTRIX Primer.

This chapter tells you how to:

Display file permissions with the 1s

—1g command and interpret the output.

Provide the minimum file permissions required for your work by setting a

restrictive file creation mask with the umask command and modifying
permissions as needed with the chmod command.
Control file access for groups of users with the chgrp command.

Create separate directories for files with similar security requirements.
Check for both suspicious files and poorly protected files with the £ind
command.

Understand how file permissions and ownership affect command execution, and
how some commands affect file permissions and ownership.
Encrypt and decrypt sensitive information.

3.1

File Types, Ownership, and the Is -lg Command
This section discusses the file types recognized by the ULTRIX operating system, the
rules that determine the owner and group associated with a file, and the output from
the 1s

3.1.1

-1g command.

File Types
The ULTRIX file system recognizes three types of files:

Ordinary

Files whose structure and contents can be controlled by users. Text
files and executable files are examples of ordinary files.

Directory

0444

Read permission.

Permission to list ( 1s) the
directory.

0222

Write permission.

Permission to add or remove
files.

0111

Execute permission.

Permission to change to a

4000
2000

Set user ID (SUID).
Set group ID (SGID).

n/a
n/a

directory (cd) or use the
directory in a search path.

Sets the effective UID or GID
of the process executing a file
to that of the owner or group of
the file, depending on whether
the "s" is in the user or group
field.

3.3

1000

Sets the sticky (save text
image) bit. Tells the operating
system to keep an executable
file in the swap area and not
overwrite it. Only the superuser

When the sticky bit is set on a
directory, only the owners of
files in the directory (or the
superuser) can delete the files.
For example, the sticky bit is

can set this bit on a
nondirectory file.

normally set on /tmp, a
directory owned by root
which contains temporary files
owned by different users.

Using Groups and Directories to Control Access to Files
In addition to using file permissions to control access to files, you can also control
access through careful use of the group mechanism and by creating directories for
similar types of files.

3.3.1

Changing the Group Associated with a File
If you own a file, you can use the chgrp command to change the group associated
with it. You must be a member of the group you want to associate with the file.
Example 3-6 shows how the groups command displays the names of groups in
/etc/group that list you as a member.

3-8 Protecting Your Files and Directories

Example 3-6:
%

Using the groups Command

groups

staff

sec pol

security

rev board

Example 3-7 shows how to use the chgrp command to change the group associated

with a file.

Example 3-7:
%

1ls

Using the chgrp Command on a File

-1g test.file

-r——r—--r--

hale

staff

chgrp security test.file

1ls

12089

Apr

09:55

test.file

12089

Apr

09:55

test.file

-1lg test.file

-r—--r-~r——

hale

security

When you change the group associated with an ordinary file, you affect only that file,
but when you change the group for a directory, any files created in that directory
from now on are automatically associated with the new group.
Example 3-8 shows how to increase security by using the chgrp command on the

directory used to store files for a specific project.

Example 3-8:

Using the chgrp Command on a Directory

Assume that you work on a project and want to maintain a common directory for

project files. This directory will be in your account. You want to allow members of
the project group to read, write and execute files in this directory, but you do not
want to give them group access to the rest of the files in your account.
1.

Ask your security administrator to create a new group in /etc/group that

contains only the members of this project. (The name of this group in the
example is project A.)
2.

Create a directory for the group:
% mkdir project_dir

Change the group name associated with the directory to project
A:
%

chgrp project_
A project dir

Set the desired permissions on the directory and check the results:
%

chmod 770 project_dir

1ls

-1ldg project_dir

drwxrwx—-——

hale

project
A

512

May

011:35

project_dir

Protecting Your Files and Directories 3-9

Note
If the members of the group want to copy files into the directory, make
sure that both the directory and the files in it have write permission set
for group. Otherwise, although the directory grants write access, the

system will not let group members overwrite a file that does not grant
group write permission. Of course, because the members of the group
have write access to the directory, they could always remove any existing
files and then copy in the newer versions, but it is easier to set write
permission for group on existing files.

To restrict the removal of files from the project directory to the owners of the files,
set the sticky bit on the project directory. As mentioned in Table 3-4, when the sticky
bit is set on a directory, only the owner of a file, the owner of the directory, or the
superuser can remove a file from the directory. The next example shows how to set
the sticky bit on a directory:
%

chmod 1770 project_dir

1ls

-1ldg project_dir

drwxrwx—-t

hale

project
A

512

May 30

011:45

project _dir

This command sets the sticky bit on the directory, grants read, write, and execute
permission to user and group, and denies all access to other.

3.3.2

Using Directories to Increase Security
You cannot set umask values on a directory-by-directory basis. The umask value
you select applies to all files created by your process. For this reason, it is a good
idea to create directories for files with similar security requirements. You can then
use the chmod command with the wildcard character (*) to set permissions for an
entire directory, rather than having to set permissions on a file-by-file basis.

3.4

Checking File Permissions and Ownership with the find
Command
If you are like most users, you eventually create numerous directories and more files
than you can remember. It is a time-consuming task to check each directory looking
for suspicious files.

To check your directories for file permissions that may need attention, use the
following shell script. A shell script is an executable text file that contains a series of
shell commands. This script also checks /tmp for any files owned by you in that

directory. If you use the script, substitute your name for username, make the script
executable, and restrict access so that only you can modify it.
/bin/sh
# This script checks file permissions and ownership on files residing in
# your account. It also looks for files owned by you in /tmp
#!

echo

find

$HOME

Files

echo

find

SHOME

echo

with Write Access

-perm -002

-exec

Files with Write Access
-perm -020

-exec

Files with Changes

3-10 Protecting Your Files and Directories

1ls

for Otherxr"

-1d

{}

;

for Group"

-1d

in the

{}

;

Last

Seven Days"

find

$HOME

echo

find

$HOME

-mtime

SUID

echo

find

$HOME
"

find

$HOME

-exec

-1d

{}

;

-exec

-1d

{}

;

-exec

1ls

-1d

{}

Files"

-perm -2000

Files

Files"TM

-perm -4000

SGID

echo

-7

Not

Owned by

-user username

echo

find

/tmp -user username

Files

User"

-exec

-1d

{}

;

/tmp"
-exec

-1d

{}
;

Because this script could produce a long list of files, you might want to redirect the
script output to a file rather than having it display only on the screen.

3.5

How File Permissions Affect Command Execution
Permissions directly affect execution of the following commands:
]

ar, cpio, and tar

]

cat, more, less, head, and tail

1ls

rmdir

In some instances, permissions inhibit command execution. For example, in order to
use the cat command to display a file on your screen, you must have execute

permission on the directory the file is in and read permission on the file.
Table 3-5 summarizes the permissions required for successful execution of several
commands. Note that you must have execute permission for each directory in the
pathname of a file, regardless of whether the file is a source file or a destination file.

Table 3-5:

File Permissions Required for Successful Command
Execution

Command
ar,

cpio,

Required Permissions
tar

Must have read permission on the source file and execute

permission on the source directory. If the destination file does not
exist, must have write and execute permission on the destination
directory. If the destination file does exist, must have write
permission on the file and execute permission on the directory.
Note that some options to these commands might affect the required
permissions.

Protecting Your Files and Directories 3—-11

Table 3-5:
Command

(continued)
Required Permissions
Must have read permission on the file and execute permission on

cat

the directory the file is in. These permissions are also the minimum
required for other commands that display a file, such as more,
less, head, or tail.

Must have execute permission on the directory you want to change

to.

Same as ar.

Hard link. A link is a directory entry that either points directly to

information about an existing file (a hard link) or points to another
directory entry for an existing file (a symbolic link). For more
information about links, see 1n(1) in the ULTRIX Reference Pages.
For hard links, must have write and execute permission on the

directory the hard link is in and execute permission on the directory
the file is in.
1ln

-s

Symbolic links. Must have write and execute permission on the

directory the symbolic link is in, do not need any permissions on
the directory the file is in. In fact, you can create a symbolic link to

a nonexistent file.
For both hard and symbolic links, the permissions on the file

determine access, not the permissions on the link.
Must have read permission on the directory.

1ls

-1

Must have read and execute permission on the directory.
Must have write and execute permission on the source directory.

Must have write and execute permission on the destination
directory. If moving a directory to another directory on the same
file system, must have write permission on the directory you are
moving plus write and execute permission on its parent directory.

If the source and destination files reside on different file systems,
mv does not rename the file, but performs a cp and an rm of the

file.
rm

Must have write and execute permission on the directory containing
the file. If there is no write permission on the file, the system

prompts for confirmation before removing the file. If the sticky bit
is set on the parent directory, must be the owner of the file, the
owner of the directory, or the superuser.
rmdir

Must have write and execute permission on the parent directory. Do

not need any permissions on the directory to be removed, which
must be empty.

3-12 Protecting Your Files and Directories

3.6

How File-Manipulation Commands Affect File Permissions
To reduce security risks, the system automatically changes the permission and
ownership associated with a file when the following commands are executed:
°

cpio

tar

Table 3-6 summarizes the actions taken by the system in these instances.
Table 3-6:

Command
cp

File Permissions Affected by Successful Command
Execution
Affected Permissions
If you copy a file and the destination file does not exist, the source
file permissions are copied with the file. However, if the source file
is owned by root and has any SUID, SGID, or sticky bits set,
these bits are not set on the destination file. Your default umask
affects the file permissions, as it does when you create any file. If
you are not the owner of the source file, you become the owner of
the destination file. If you copy a file to a directory owned by
another user, you are still the owner.

If the destination file exists, the source file overwrites it (only if
write access is allowed), but the permissions are not affected.
cpio

If you use cpio to copy files from an archive, you become the
owner of the files. Only the superuser can copy files into the system
and have the files retain their original owners. Because ownership is
affected when copying files into the system, physical protection of
archive media is important. If you copy all your files to a tape and
another user obtains the tape, that user can recreate your files and
become the owner.

You can create a hard link (1n) to a file only if the link and the file
are on the same file system. This limitation exists because any hard
links to the file, and the initial directory entry for the file, contain
the inode number of the file. (The inode number identifies a
structure that contains information about the file, such as its actual
location, permissions, and file type. The 1s -1i command
displays a long listing which includes the inode numbers for your
files.)

Protecting Your Files and Directories 3-13

Table 3-6:

(continued)

Command

Affected Permissions
You can create a symbolic link (1n

-s)

to a file on your file

system or another file system. A symbolic link points to another

directory entry, not to the file itself.
The link count is the number found between the file permissions
and the file owner in a long listing (1s

-1). You can check the

link count on a file to determine if there are any hard links to the

file. You will always have at least a link count of 1 because your
directory entry for the file is a hard link. A link count of 3
indicates 2 other hard links to the file.

If you remove a file with hard links to it, you have only removed
your hard link to the file. The other hard links can still access the

file, even though you cannot. For this reason, always check the link
count on a file before using the rm command to remove the file. If

other hard links exist, strip all the permissions from the file before
removing it.
mv

Moving a file within your own file system does not change

ownership and permissions. However, when you move a file from

another file system to yours, you become the owner (if you are not
already) and your umask value affects the permissions. In addition,
any links to the original file are lost.
tar

3.7

Similar to cpio command.

Using Encryption to Protect the Contents of a File
For security reasons, file encryption commands are distributed as an option in the
ULTRIX V4.0 release. If the encryption commands are available on your system, you
can use the crypt command to encrypt sensitive files.

short file looks before and after encryption.

Example 3-9:
%

cat

this
%

File Encryption

input_file

crypt

an
<

encryption test
input_ file

Enter

key:

output_file

cat

hide
me 1

1X)

3-14 Protecting Your Files and Directories

output file
<key

not

displayed>

Example 3-9 shows how a

You could then delete the input file, leaving only the encrypted version. To retrieve
the information in the encrypted file, use the crypt command but reverse the order
of the files. Example 3-10 shows how to decrypt the file from Example 3-9.

Example 3-10:
%
[o)

crypt < output file > restored file

Enter key:
%

File Decryption

cat

this

hide
me 1

<key

not

displayed>

restored file
is

encryption

test

The encryption distribution also includes encryption files for use with the standard
ULTRIX editors ex, vi, and ed. Refer to the manuals for these editors for more
information.

3.8

Security Summary
Because you control file permissions on your files, understand the range of available
security options, and choose those options that best fit your security needs.
e

Know how the system assigns owners and groups to files.

Set a reasonably restrictive umask value in your shell startup files (for
example, umask

027).

Provide only the minimum file permissions required for your work. You only
ask for trouble when everyone can access your files. Use the chmod command
to modify permissions as needed.

Use the group mechanism to control file access when you need to share files
with other users.

Create separate directories for files with similar security requirements.

Use the

£ind command to check for suspicious files and files with insecure

permissions.

Understand the interaction between certain system commands (such as mv
or cp) and file permissions and ownership.

Protect removable media. If someone copies your files into the system using the
cpio command, that user becomes the owner of your files.

Understand how links operate on files.

Encrypt extremely sensitive information.

Protecting Your Files and Directories 3—15

Processes and Shells

To the ULTRIX operating system, you are defined by the files you own and the
processes running on your behalf. Chapter 3, ‘‘Protecting Your Files and
Directories,”” looks at files and how to protect them. This chapter does the same for
processes by:

Providing a general description of a process.

Explaining the differences between real and effective UIDs and GIDs.

Discussing how SUID and SGID programs use effective UIDs and GIDs. These
programs perform a valuable service, but their use without proper understanding
increases security risks.

Looking at shells and how to protect your shell startup files.

Understanding file permissions makes you aware of the security issues involved in
protecting files; understanding processes increases your ability to control and monitor
the security of your working environment within the system.

4.1

What s a Process?
A process is the content (code) and the context (environment) of an executing
program. Processes perform actions and accomplish tasks within the system. Some
processes are created at system startup, and run until the system is shut down; for
example, the swapper, init, and pagedaemon processes. Some processes are
started when a user logs in, and run until the user logs out; for example, your login
shell. Other processes exist only for the time required to perform a task. For
example, when you type the 1s command, a process is created and exists until the
command finishes execution.

Processes can create other processes with the fork () system call.

A process that creates another process is called the parent process. The created
process is called a child process.

A parent process can have more than one child process. However, a child
process can have only one parent process.

A child process can create its own child processes. Thus, a process can be a
child of one process, yet be a parent to other processes.

Each process has a unique identifier, called its process ID (PID). Each process
knows its own PID and its parent’s process ID (PPID). A child process is a
copy of the parent process, except for its PID and its PPID, until it executes an
execve () system call.

Each process has an owner, identified by the UID associated with the process.

A process can exit when its task is finished through the exit () subroutine, or
can be terminated with the k111 command or other termination signals.

Figure 4-1 shows the relationship between parent and child processes.

Figure 4-1:

Parent and Child Processes
parent process to:

PID

= 101

PID

=102

PID

= 103

PID
PPID

child process of:

PID

child process of:

=100

child process of:
PID

PID

= 100

=100

parent process to:

PID

110

PID

111

PID

110

PID

111

PPID

102

PPID

102

The system controls file access by comparing the UID and GIDs associated with a
process to the UID and GID associated with a file. This is why you can use the
chmod command to modify the permissions on your files, and the reason why you
cannot modify the permissions on another user’s files.

To display process information, use the ps command. You could, for example, use

the —1 and -t options to display a long listing of processes at the current terminal.
In the following example, the name of the command executing in a process is listed
under the COMMAND heading.

4-2 Processes and Shells

Example 4-1:
% ps

Using the ps Command

-1t

PID

PPID

RSS

WCHAN

STAT

TIME

COMMAND

408201
p008021

UID

179 13824
179 22002

1
13824

3
32

PRI NI ADDR

15
33

031b86
36
034064 211

33
1954

fe400

s
T

18
18

0:02
0:00

sh
emacs

b000001

179 22110

13824

028eal

188

0:00 ps

296

-1t

In the preceding example, a user with UID=179 owns the processes. From the PID
and PPID information, you can see that the sh process (PID=13824) is the parent
process of the emacs process (PID=22002) and the ps process (PID=22110). For
more information on the ps command, see ps(1) in the ULTRIX Reference Pages.
It is a good idea to check your processes occasionally. If you find a process that you
own but cannot identify, you can terminate it with the ki1l command, using the
number of the unwanted process as an argument. For example:
%

22002

kill

For more information on the ki1l command see ki11(1) in the ULTRIX Reference
Pages. Use the ps command to verify that the process has terminated:
%

-lt

b408201
b000001

UID

PID

179 13824
179 22122

PPID CP

1
13824

3
51

PRI NI ADDR

15
37

031b86
36
012c80 296

RSS WCHAN STAT TT

TIME

33
188

0:02 sh
0:00 ps -1t

fe400 s
R

18
18

COMMAND

Exercise caution when terminating a process. For example, you do not want to
terminate a batch job by mistake. One thing to check for would be a process owned
by you but attached to a terminal you are not using. If in doubt, check with your
security administrator before terminating an unknown process.

4.2

Real and Effective UIDs and GIDs
While the system assigns a UID and a GID to each file, each process has a real and
an effective UID and a real and an effective GID. When determining what a process
can do, the effective UID and GID are the IDs that count. They determine the actual
capabilities of the process.

Real UID

The UID of the owner of the process.

Effective UID

The UID that determines the user access rights of the process. The
effective UID is usually the real UID. However, in a set user ID
(SUID) program, the effective UID is changed in order to modify
the user access capabilities of the process.

Real GID

The GID of the owner of the process.

Effective GID

The GID that determines the group access rights of the process. The
effective GID is usually the real GID. However, in a set group ID
(SGID) program, the effective GID is changed to modify the group
access rights of the process.

Your UID from /etc/passwd becomes both the real UID and the effective UID
for your login shell. Any process created by your shell inherits these UIDs. Any file

Processes and Shells 4-3

you create is assigned your effective UID. Unless you execute an SUID program or
run another program that changes your real or effective UID, your UID from
/etc/passwd is propagated consistently during your session.

Your GID from /etc/passwd is considered your primary GID. This primary GID

becomes both the real GID and the effective GID for your login shell.

Your process

also has a group access list, which includes your secondary GIDs from
/etc/group plus your primary GID. When your process attempts group access to

a file, the system checks your effective GID and and all the GIDs in your group
access list looking for a match to the GID associated with the file. If any of your
GIDs match that of the file, you are allowed group access to the file. Figure 4-2

illustrates this concept. Note that your primary GID is added to the group access list
to facilitate file access in SGID programs, where your effective GID is no longer your
primary GID.
Unless noted, any discussion of real and effective UIDs applies to real and effective
GIDs.

Figure 4-2:

GIDs and the Group Access List

/etc/passwd

primary GID

/etc/group

group access list
(groups from /etc/grou

plus primary Gl%) g

real GID

effective GID

(stored separately from
group access list)

file access determined by
effective GID plus
group access list

4—4 Processes and Shells

To display your real UID and GID, use the id command. For example:
%

uid=179 (hale)

gid=15(staff)

The id command displays the effective UID or GID only if different from the real
UID or GID. In the following example, a process owned by root executes a
program that changes the effective UID.
%

uid=0 (root)

gid=1l (daemon)

euid=179 (hale)

Because the effective UID determines user access rights, any process with your

effective UID has your rights. If another user owns a process with your UID as the
effective UID, your account is as much at risk as if that person knows your password.
For this reason, do not execute an unknown program. Because you create the process
that executes the program, the process would have your UID as its effective UID and
can access your files and directories.

The following rules apply to any process that attempts to access a file:
e

If the process’s effective UID equals the file’s UID, the process has the owner’s
access rights. The file’s user permissions allow or deny access.

If the process’s effective GID, or any of the GIDs in the group access list,
equals the file’s GID, the process has the access rights of the group associated

with the file. The file’s group permissions allow or deny access.
e

If the process’s effective UID or GID does not equal the file’s UID or GID, the
file’s other permissions allow or deny access.

If the process’s effective UID=0, the rules do not apply. Any process with an
effective UID=0 has superuser privileges. It therefore has almost unlimited
access to the operating system and user files. (For obvious reasons, a process
whose effective UID=0 is called a privileged process.) The only limits are
those placed by the system on operations that are considered unreasonable; for
example, only a process that locks a file can unlock it. However, a process with

an effective UID=0 could terminate the locking process and thereby release the
lock.

The following section looks at how a process can have an effective UID or GID that
differs from the real UID or GID.

4.3

SUID and SGID Programs
Set user ID (SUID) and set group ID (SGID) programs change the effective UID or
GID of a process to the UID or GID of the program. They are a solution to the
problem of providing controlled access to system-level files and directories, because
they grant a process the access rights of the file’s owner. However, a poorly written
or poorly protected SUID program presents a potential security risk, especially if the

program is owned by root. Consider an SUID program owned by root that let a
user escape to a shell. The user now has same privileges as the system manager, and

the opportunity to exercise them.
The same logic applies to your account. Do not make a program that you own SUID
or SGID without good reason. Under normal circumstances, ordinary users do not
need SUID or SGID programs. If you must have an SUID or SGID program to
provide controlled access to a file you own:

Processes and Shells 4-5

4.3.1

Make sure that you know exactly what the program does. If you have any
doubts, check with your security administrator before making the program
SUID or SGID. Note that your security administrator can mount a file system
nosuid, which allows an SUID or SGID program to execute, but does not
allow the effective UID or GID to change from the real. This has the effect of
reducing the program to a normal executable program.

Make sure that only you can read or modify the program.

Keep the program in a separate directory with restrictive permissions on the
directory. Only you should have write permission to the directory. You may
want to remove read permission for group and other to keep casual browsers
from learning that you have SUID or SGID programs.

Example of an SUID Program
Whenever you change your password, you execute an SUID program. The passwd
program is SUID to root to allow users to write to /et c/passwd, a file owned
by root. Figure 4-3 shows the ownership and permissions on /etc/passwd; it
also shows that an ordinary user does not have a UID or GID that would allow user
or group access to /etc/passwd.

Figure 4-3:
$

1ls

SUID Program

-1g /etc/passwd

-rw-r--r-—

$cat

root

/etc/passwd

system

4068

Apr

09:55

/etc/passwd

grep root

root :KM8Fab5UT7NS3e:0:1:System PRIVILEGED

Account,,,,:/:/bin/sh

root’s UID —-T t— root's GID
$cat

/etc/passwd

grep hale

hale:L8bE25dA4nm2:179:15:Harriet

hale’s UID

Hale:/usr/users/hale:/bin/csh

hale’'s GID

If there was no mechanism to allow users controlled access to certain system files
like /etc/passwd, the following problem would exist:
e

Only the owner of /etc/passwd could write to the password file. The file is
owned by root (UID=0). Therefore any process that wants to modify this file
must have an effective UID=0 to gain user access rights, or an effective GID=1
(system) to gain group access rights.

The user in the example (hale) has UID=179 and GID=15. A process created by
this user has an effective UID=179 and an effective GID=15. Suppose the user
also belongs to three other groups from /etc/group, but none of these has
GID=1. Because neither the UID nor and GIDs associated with the process

4—-6 Processes and Shells

match those assigned to the /et c/passwd file, this user is considered other
when file permissions are checked. Neither group nor other has write access to
/etc/passwd.

]

Therefore, the user cannot write to /etc/passwd. Because only the owner
can write to the file, the security administrator (who has superuser privileges)
would have to change passwords for all users.

However, because the passwd program is owned by root and is an SUID program,

you can write to /etc/passwd and change your own password, but only under the
control of the passwd program. Use the 1s

-1 command to look at the

permissions on the passwd program.
% 1s
[}

-1

/usr/bin/passwd

-rwsr-xr-x

root

system

17408

Oct

1988

/usr/bin/passwd

The letter ‘‘s”’ in the user execute permission indicates that the program is an SUID
program. When you execute an SUID program, a child process is created with your
real UID but with an effective UID of the owner of the SUID program. This child

process now has the access rights of the owner of the SUID program (not a trivial
issue when the SUID program is owned by root).

When the child process exits,

your parent process resumes execution and your effective UID is once again the same
as your real UID.

When you execute passwd, your effective UID=0 because root owns
/usr/bin/passwd.

Because all file access to /etc/passwd takes place under

program control, you cannot abuse superuser privileges while your child process is

executing with its effective UID=0.

4.3.2

Example of an SGID Program
An SGID program is similar to an SUID program, but group access is in effect rather
than user access. You must be a member of the group associated with an SGID file to
run the program. A program can be both SUID and SGID; they are not mutually
exclusive.
The following example shows the permissions on three programs that are both SUID
and SGID.
% 1s

-1g /usr/ucb/lp*

-rws--s-—-x

root

daemon

50176

Oct

1988

/usr/ucb/lpg

-rws--s—--x

root

daemon

44032

Oct

1988

/usr/ucb/lpr

-rws—--s—-—-x

root

daemon

53248

Oct

1988

/usr/ucb/lprm

These are the programs you use to check print queues, send a file to a print queue, or

remove a file from a print queue. They are SUID/SGID to allow you to put files in
and remove files from directories that would normally deny you access. A process

executing any of these commands has an effective UID=0 and an effective GID=1.
These are the UID and GID assigned to the respective account entries for root and
daemon in /etc/passwd.
% egrep

’'“root|*daemon’

/etc/passwd

root :KM8Fa5UT7NS3e:0:1:System PRIVILEGED Account,,,,:/:/bin/csh
daemon:*:1:1:Mr Background:/:

Processes and Shells 4-7

Figure 4-4 shows how the passwd program changes a user’s effective UID and how
the 1pr program changes a user’s effective UID and effective GID.

Figure 4-4:

SUID and SGID Programs
login process (shell)

/etc/passwd —fi uib = 179

EUID = 179

fetc/passwd —4+—>

GID = 15
EGID = 15

/etc/group —(any additional GIDs

user Hale runs passwd program

SUID to root (file UID = 0)
child process

fork()

(

uiD = 179

EUID = 0

GID = 15

user Hale runs lpr program

EGID = 15

SUID to root (file UID = 0)
SGID to daemon (file GID = 1)

(EUID is now 0)

child process

(

UID = 179

EUID = 0

\ fork()

GID = 15
EGID = 1

(EUID is now 0)

(EGID is now 1)

‘
login process

continues

4.3.3

Copying and Moving SUID and SGID Programs
You can copy (cp) an SUID or SGID program from another user’s account if you

have read and execute permission on the source directory. The copy in your account
retains its SUID/SGID permissions, but you become the owner. However, if the

source file is owned by root, the system always removes SUID/SGID permission
when the file is copied.
If you have a file with the same name as the SUID/SGID program, the copy takes the

place of the original file, but the original permissions apply.
You can move (mv
) an SUID or SGID program from another user’s account to your

account if you have write and execute permission on the source directory. If both
files are on the same file system, the ownership is not changed, and SUID/SGID
permissions are not removed. If the files are on different file systems, the ownership

is changed, and the SUID/SGID permissions are removed.

4-8 Processes and Shells

4.4

Shells
Your login shell is the first process created with your UID and GID at login. In one

sense, a shell is just another process; it has a PID, a PPID, and an owner. However,
your shell is special because it is the environment in which you operate as a user.

4.4.1

Supported Shells
The ULTRIX operating system supports four shells:
L

Bourne shell (sh)

C shell (csh)

sh5 shell (sh5)

KornShell (ksh)

Each shell reads one or two startup files at login. Usually your security administrator
installs a basic version of these startup files when creating your account. Most users
modify these files to create a comfortable working environment. If you are not
careful, you can unintentionally make your account vulnerable to the most simple
forms of prying. However, with a little forethought and care these files not only
create a comfortable environment, but a reasonably secure one.

Some shells read a second file when executed as a command. This allows the passing
of environment variables that would not normally be inherited by a child process.
Bourne Shell

Reads .profile at login.

C Shell

Reads .login and .cshrc at login. Reads . cshrc when
invoked after login.

shS Shell

Reads .profile at login.

KornShell

Reads .profile and .kshrc at login. Reads .kshrc when
invoked after login.

4.4.2

Creating Secure Shell Startup Files
Your shell startup files are in your account and owned by you. The contents of these
files and the order in which variables appear directly affect the security of your
account.

Some basic rules for your shell startup files:

Use absolute pathnames, ones that start with root (/). For example:
PATH=/bin:/usr/bin/:/usr/local/bin:$HOME/bin:
The shell searches the directories in the order listed in PATH. If you have a
SHOME/bin directory, make sure that only you can write to it. Otherwise,
someone could substitute a Trojan horse program for one of your programs.
You would execute the Trojan horse program when you thought you were
executing one of your own. (Trojan horse programs are described in Chapter 1.)

Put the PATH variable before any other variables in your startup file to ensure
absolute pathnames from the start of the session.

Processes and Shells 4-9

Make sure that your PATH is passed to any processes you create. For example,

in the Bourne shell:

export PATH
In the C shell, put PATH in your . cshrc file rather than your . login file.

This ensures that the PATH variable is passed to processes started by your login
shell.
*

Do not put the current working directory (.) in PATH. Whenever you use the
cd command to change to a directory, you could unknowingly execute a file

placed in that directory to trap an unwary user. Putting the current working

directory in your startup files makes every directory in the system a potential
mine field.
*

Do not put a directory like /tmp or /usr/tmp in PATH. Any user can put a
file in these directories. A user could hide an executable file with the name of a
real system command, hoping to trap someone whose PATH looks at /tmp

before looking at the standard system directories where user commands are
stored.
e

Since these files are read by the login process, it is important to prevent them

from being modified. Set the protections on any shell startup files to restrict
read and write access to yourself. Unless there is a good reason for not doing
s0, remove both group and other access to these files. For example:
%

chmod

600

.profile

To check the permission:
%

1ls

-1

.profile

—FW———————

hale

732

Mar

9:22

.profile

Note that denying other users read permission does not mean that they cannot
find your PATH or any other of your environment variables. The —eaxww

options to the ps command display in wide format the environment variables
for all processes on the system.
®

Set arestrictive umask value (for example: umask 027) in your startup files.

The following example shows a template that you can use to begin creating a secure
.profile file for the Bourne shell. Apply the same principles if you are creating a
. login file for the C shell (remember to put PATH in . cshrc for the C shell).
#!

/bin/sh

#
# use absolute pathnames
#
# (note:

put

in PATH

your executables

$HOME/bin)

#
PATH=/bin:/usr/bin:/usr/local/bin:/usr/ucb:/etc:/usr/local/man:S$SHOME/bin
export

#
#

PATH

set a restrictive umask

#
umask

027

#
# don’t

allow other users

#
mesg

4-10 Processes and Shells

to write to your terminal

4.4.3

Shell Scripts
Many users create shell scripts to handle repetitive tasks.

Since a shell script is a text

file, it must provide read and execute access to whoever executes it. Because any user
who can execute the script can also read it, a window of opportunity exists for

sophisticated but unprincipled users. They could take advantage of the power inherent
in the various shell programming languages to make the script perform actions that

you did not intend. To reduce the risk of executing an illicit program, explicitly set
the absolute search path for any program invoked through a shell script.

Set

restrictive permissions on any Scripts you own.
Because a shell script is readable, it is inherently more open to compromise than a
compiled program. If possible, create a compiled program rather than a shell script.
Do not make a shell script SUID. Because a shell script is less secure than a
compiled program, you increase the risk that someone could compromise the script

and gain control of a process that has your effective UID. Note that the security threat
is even greater if you have superuser privileges and create an SUID shell script
owned by root. A compromised SUID root shell script provides an attacker or
malicious insider the potential to create a process with an effective UID=0.

4.5

Security Summary
Just as you own your files and directories, you own the processes you create. Because

processes perform actions in your behalf (and with your privileges), you should know
what rules govern a process’s ability to read your files.
¢

Understand how the system identifies your processes, and the difference

between real and effective UIDs and GIDs.
¢

Do not execute an unknown program. It will have your effective UID and GIDs

— and therefore your rights.
e

Use the ps command to keep track of your processes. This enables you to kill
any suspicious processes, and alerts you to any runaway processes that are
monopolizing system resources.

Know how SUID and SGID programs work. Be aware of the potential risks
when these mechanisms are used carelessly or when source files are poorly

protected.

Use your shell startup files to create a secure environment. Watch out for the
more common dangers, such as using relative rather than absolute pathnames
when defining the PATH variable. Put restrictive permissions on your shell
startup files.

Because shell scripts must be readable by those who execute them, they are less
secure than compiled programs.

Processes and Shells 4-11

Connecting to Other Systems

While connecting systems gives users greater access to information, it also magnifies
the security risks for each system. Responsible network security allows users some

freedom while protecting valuable files from would-be attackers.
Your security administrator is responsible for most network security issues.
However, individual users are responsible for being alert to security risks and

protecting their accounts and files.
Four networking protocols enable ULTRIX users to communicate with users on
remote systems:

Internet protocols (TCP/IP, FTP, and TFTP)

Local Area Transport (LAT)

The uucp utility

DEChet

Each protocol has its own scheme for handling communication between systems on a
network. This chapter describes the security risks in using commands that connect to

other systems using each of these protocols and offers suggestions for minimizing
those risks.

5.1

The rlogin, rcp, and rsh Commands
The TCP/IP protocol is the most commonly used networking protocol running under
ULTRIX software. With TCP/IP, much of the network access to the computer is in
the hands of users. TCP/IP commands that enable you to communicate with remote
systems are:

rlogin

Lets you log in to a remote system. This command connects your

terminal on the local host system to another login session either on a
remote system or on the local host system. For more information on the
rlogin command, see riogin(lic) in the ULTRIX Reference Pages.
rcp

Lets you copy files to and from remote systems. For more information
on the rcp command, see rcp(lc) in the ULTRIX Reference Pages.

rsh

Lets you connect to a specified host and execute a command on the
remote host. This command is a conduit to the remote command, passing
it your input for processing and returning to you its output and any error
messages that it generated. For more information on the rsh command,
see rsh(lc) in the ULTRIX Reference Pages.

A security risk in using the rlogin, rcp, and rsh commands lies in the network
files, /etc/hosts.equiv and .rhosts, that these commands check before
connecting to a remote system.

5.1.1

The /etc/hosts.equiv File
The /etc/hosts.equiv file, which is owned by root, contains a list of host
systems that are equivalent to your local host system. Users on equivalent hosts can

log in to their accounts on the local host, without typing a password. The user name
on the remote and local host must be identical.
Equivalent hosts can be remote hosts or the local host. If the local host is listed in the
/etc/hosts.equiv file, users logged in to the local host can remotely log in to
their own accounts on the local host, without typing a password.

For security reasons, the /etc/hosts.equiv file does not allow a superuser
logged in on a remote system to log in to the local host without typing a password.
For more information on the hosts .equiv file, see hosts.equiv(Syp) in the

ULTRIX Reference Pages.
Because the /etc/hosts.equiv file is a remote system’s key to your system,

security-conscious security administrators leave this file empty or carefully restrict
access to systems. If your security administrator leaves the /etc/hosts.equiv

file empty, the only way that a user on a remote host can log in to the local host
without typing a password is by logging in to your account, if his or her user name is
listed in your

5.1.2

.rhosts file.

The .rhosts File
The .rhosts file is a list of equivalent hosts that any user can create in his or her
home directory. This file is the user counterpart of the /etc/hosts.equiv file.
The

.rhosts file has a narrower focus than its system-wide counterpart. The

/etc/hosts.equiv file can affect the accounts of many users on a system,
including yours. The

Your

.rhosts file affects only your own account.

.rhosts file enables users with your user name on equivalent hosts to log in

to your account on the local host, without typing a password. The user must have a
.rhosts file in his or her home directory.

Note
Equivalent hosts can be remote hosts or the local host. If the local host

is listed in your

.rhosts file, users with your user name, logged in to

the local host, can remotely log in to your account on the local host,
without typing a password. Including the local host in your

.rhosts

file enables you to remotely log in to your account and start a new
session on the local host.

If you list a user name other than your user name next to the host name in your
.rhosts file, that user can log in to your account on the local host. In this case,
the remote user does not need an account on the local host or a .rhosts file in his
or her home directory on the remote host. For example, the following entry in Peter’s
.rhosts file allows Paul to log in from rook as Peter without typing a password.
rook

paul

The most common use of the

.rhosts file is to simplify the remote logins between

multiple accounts owned by the same user. If you have active accounts on more than
one system, you may need to copy files from one account to the other or remotely
log in to one account from the other. The
type of use.

5-2 Connecting to Other Systems

.rhosts file is ideally suited to this

Your .rhosts file can expand the access that the /etc/hosts.equiv file
grants to your account. But, the .rhosts file cannot restrict that access. When a
user executes the rlogin, rcp, or rsh command, that user’s .rhosts file is
appended to the /et c/hosts.equiv file for permission checking. The entries in
the combined files are checked in sequence, one entry at a time. When the system
finds an entry that grants access to the user, it stops looking. The entries in the
/etc/hosts.equiv file are checked before the entries in the .rhosts file are
checked. However, when the user is root, only the .rhosts file is checked.

If your security administrator excludes a user from the /etc/hosts.equiv file,
but you include that user in your .rhosts file, that user is considered trusted and
can log in to your account without entering a password. The converse is not true. If
your security administrator includes a user in the /etc/hosts.equiv file, you
cannot exclude that user from accessing your account.

Security Tips

Follow these guidelines to protect your files against attack through the rlogin,
rcp, and rsh commands:

Check your file permissions. Your home directory should deny all access to
other, and write access to group. The permissions on the command and
configuration files, such as .profile, .login, .logout, .cshrc, and
.forward, should deny all access to group and other.

For example, use the chmod command to change the protections on those files
from your home directory, as follows:
%

chmod 750 $HOME

% chmod 600

.profile

.login

.logout

.cshrc

.forward

If you do a long listing of your home directory, your file protections should
look like these:
%$1ls -al
drwxr-x———

fields

512

Jun

—rw———————

fields

419

Jun 2

11:46

08:28

.login

Use the chmod command to set the permissions on your .rhosts file to 600.
Chapter 3 discusses protecting your files and directories.

Include in the .rhosts file only the current remote hosts from which you
would like to issue remote commands. It is wise to list only hosts on which
you have accounts. If you are unsure about which hosts to include in this file,
check with your security administrator.

You should be the owner of your .rhosts file, and it must not be a symbolic
link to another file.

5.2

The ftp Command
The ftp command enables you to transfer files to and from a remote site, using the
ARPANET standard File Transfer Protocol. In autologin mode, £tp checks the
.netrc file in your home directory for an entry describing an account on the remote
host. If no entry exists, £tp uses your login name on the local host as your user
name on the remote host, and prompts for a password and, optionally, an account for
login. Because your £tp login to a remote system is in essence a remote login to
that system, you have the same access to files as if you, rather than ftp, had actually

Connecting to Other Systems 5-3

logged in. For more information on the ftp command, see ftp(lc) in the ULTRIX
Reference Pages.
A security risk in using ftp is the practice of creating the anonymous account, a

generic account that the £tp command recognizes. The anonymous account
usually has a commonly known password or no password, and it allows users to log

in and transfer files to your system from a remote system with no audit trail. Security
administrators concerned with network security avoid creating such anonymous
accounts.

You should know and follow the security policy on using ftp for file transfers to
remote systems. Talk to your security administrator about the security controls at

your system. As mentioned previously in this chapter, use the chmod command to
properly protect your files.

5.3

The tftp Command
The t £tp command provides an interface to the Internet Standard Trivial File
Transfer Protocol. Like the £tp command, this command enables you to transfer
files to and from a remote network site. However, the t ftp command does not
request a password when you attempt to transfer files. Therefore, any user who can

log in to a system on the network can access remote files with read and write
permission for other. Since the t £tp protocol does not validate user login

information, setting proper permissions on your files is the only real protection from
unauthorized access.

5.4

Local Area Transport (LAT) Commands
Your security administrator can increase the security of the LAT protocol service by

configuring LAT groups of hosts that can communicate only with each other or
through specified terminals. A host can be set up to listen for connections from
certain groups of terminal servers (those connected to terminals, for example) while
ignoring connections to all other LAT servers. For more information on using the
LAT protocol, see 1cp(8) in the ULTRIX Reference Pages.
Your security administrator can also set up LAT and hardwired terminals as secure

terminals. If your security administrator has set up your terminal with a trusted path,
you can press the Secure Attention Key (SAK) to log in to the host. Pressing this

key kills any currently executing process prior to starting the login at your terminal.

The login process proceeds as usual. The BREAK key may be configured as your
Secure Attention Key. If your terminal connects to a terminal server that supports
multiple sessions, and the BREAK key is normally used to display the terminal
server prompt, you should remap this key. For example, to change the terminal

server attention key on a DECserver 200 from BREAK to

type the

following at the LOCAL> prompt:
LOCAL> set port local|CTRL/A

5.5

The uucp Utility
The uucp utility is a group of programs that enable you to connect to remote
systems using a modem and telephone lines. The uucp utility is widely adopted by

most UNIX systems and enables you to transfer files between remote systems and the
ULTRIX operating system. In addition, your system can use uucp to send and

5-4 Connecting to Other Systems

receive mail across telephone lines.
Three uucp commands can present security concerns:

5.5.1

uucp (UNIX-to-UNIX copy)

tip

The uucp command
The uucp command is the UNIX-to-UNIX copy command. This command is the
main interface to the uucp utility.

The uucp utility enables users on remote systems to access those files and
directories for which your security administrator has granted permission. For more
information on the uucp command, see uucp(lc) in the ULTRIX Reference Pages.
The uucp utility, left unrestricted, allows any user to execute any command and
copy any file that is readable or writable by a uucp login user. Individual sites
should be aware of this potential security risk and apply any necessary protections.
Your security administrator exercises security measures when installing and setting
up the uucp utility on your system. The following guidelines protect against
unauthorized use of this powerful utility:

Create a directory in your account for uucp. Use only this directory for all
uucp transactions.

Use the chmod command to set the sticky bit on this uucp directory. When
the sticky bit is set on a directory, only root or the owner of a file can remove
files from the directory. You will not be able to remove those files while the
sticky bit is set, and you may have a disk space problem. If this happens,
remove the sticky bit from your directory and remove the excess files. For
more information on setting the sticky bit, see the chmod(1) command in the
ULTRIX Reference Pages. The following example sets the sticky bit on the
documents directory:
%

chmod 1777

documents

Unless you have set up a separate uucp directory, always copy files to or from
the /usr/spool/uucppublic directory.

5.5.2

The tip and cu Commands
The tip and cu commands enable you to call another system, log in, and execute
commands while you are still logged in to your original system. The tip and cu
commands are two different interfaces to the same program. These commands
connect your terminal to a modem on your system. You need only tell tip or cu
what telephone number to call. For more information on the tip and cu commands,
see tip(lc) and cu(lc) in the ULTRIX Reference Pages.
The following example shows a session using the cu command:
%

4783939

connected

A security concern about using the tip and cu commands is that everything you

Connecting to Other Systems 5-5

type is read by the command and passed to the remote system. This can be
dangerous if the remote system is not a trusted system. A Trojan horse version of cu,
for example, could store your login name and password on a remote system. Follow
these general security guidelines for using commands that start remote sessions:
®

Be sure that the program you are using is the authentic program.

Do not use a

terminal that seems already to be running tip or cu; reinvoke the command.
e

Do not use an automatic login procedure, such as sending your remote password

from a file on the local computer.

If you are capturing the session transcript into a local file, begin the capture
only after completing remote login.

Capture only the data you need; avoid

capturing the dialogue you used to obtain the data.
*

Avoid leaving your terminal or using your terminal for other things while a

remote session is in progress. If your connection with the remote system is
broken, immediately reestablish contact, check to see if your first session left
any processes suspended, and kill those processes.

5.6

The dlogin, dis, and dcp Commands
If DECnet-ULTRIX is installed on your system, you can use the following DECnet
commands to communicate with remote systems running the DECnet protocol:
o

dlogin

dls

dcp

Your security administrator can increase DECnet security on your system by not

creating a generic guest account for remote DECnet connections. Without this
default user account, remote users must specify a valid user name and password
either on the command line or interactively. For example, to copy a file from one
system to a remote UNIX system without a default user account, you would have to
type:
dcp localfile

remote node/remote user/remote passwd::/remotepath/file

If you are connecting to a remote system that has no default user account, you must
include this user name and password information in the command. If you do not
specify a password, you will be prompted for one. This provides more security
because some shells (for example, the C shell) can maintain a history file. If you keep
a history file and enter your password in clear text on a command line, the password
is stored in the history file. For more information on using these commands, see the
DECnet—-ULTRIX User’s and Programmer’s Guide.

5.7

Security Summary
Although security administrators are responsible for establishing and enforcing
network security policy, network security is everyone’s concern. You can protect
your account and files by doing the following:

Set appropriate permissions on your directories and files. For more information
on setting file permissions, see Chapter 3.

Be aware of the security policy for using your network and work closely with

your security administrator to implement that policy in your account.

5-6 Connecting to Other Systems

Carefully control the contents of network access files, such as

.rhosts and

.netrec.

Create a directory in your account for uucp, and use the chmod command to
set the sticky bit on this directory.
When you use the tip or cu command, never use an automatic login
procedure and never leave your terminal while a remote session is in progress.
If you are capturing the session transcript into a local file, begin the capture

only after completing remote login. Capture only the data you need; avoid
capturing the dialogue you used to obtain the data.

Connecting to Other Systems 5-7

Workstation and Windowing Environments

This chapter discusses DECwindows features that enhance the security of a
workstation. This chapter does not explain how to use DECwindows. For

information on using DECwindows, see the DECwindows User’s Guide.

6.1

Who Can Access Your Workstation Display?
When you log in to a workstation and create a session, your workstation determines

which hosts are authorized to access its display. Every user who can log in to an
authorized host has the following kinds of access to your workstation:
*

Read. Users can read the contents of one or more windows on your
workstation. When you press a key on your keyboard a character representing

the key appears on your workstation screen. Thus, you can see what you type
on your screen. Any user on a host that is authorized to access your display

could divert your keystrokes to another workstation display. An unscrupulous
user could capture and display keystrokes (including your password) on another
system.

Write. Users on authorized hosts could also send simulated keystrokes to your
workstation display. Your workstation software treats the keystrokes the same
whether you type them from your keyboard or an application program sends
them.

Users on authorized hosts can send commands to your workstation —

and every command is executed under your user login and password. Imagine
someone sending these commands to your workstation!

SHOME

—-rf

Copy. Users on authorized hosts could also capture a snapshot of any one of
your windows or your entire workstation screen, without your knowledge. This
snapshot is a static picture of the contents of your display. A good rule of
thumb 1is that if you can see it on your display, any user on an authorized host

can see the same thing.

6.2

Controlling Network Access to Your Workstation
Controlling access to your workstation display is the key to creating a secure

workstation environment. Your workstation keeps an access control list, which names
the hosts on a network that can access its display. This list is a combination of a
system list that your security administrator creates and a personal workstation list that
you create.

Remember that hosts that are authorized to access your workstation display can read
it, write it, and copy it at any time. Restricting access is the only way to prevent
users from taking a snapshot of the contents of your workstation display.

Thus, there are two ways to determine which hosts can access your workstation
display:

6.2.1

The system access control list

The workstation access control list

The System Access Control List
Your security administrator can authorize a host to access a workstation’s display by
adding the host name to a system-wide authorization file called /etc/X* .hosts.

The asterisk (*) refers to the number of the workstation display that the hosts listed
in the file can access. The standard display number is zero (0). Hosts that are not
listed in this file cannot access your workstation display. When shipped with your
system, the /etc/X* .hosts file is empty, which means that only your workstation
(the local host) can access its display.
The /etc/X* .hosts file is a system-wide access control list for your workstation.

Each time you start a session on your workstation, the hosts that are named in this
file are authorized to access your workstation display.

6.2.2

The Workstation Access Control List
Your workstation access control list can allow hosts access to your workstation
display, even though the system access control list does not. You can thus explicitly
authorize other users or yourself, when you are logged in from another host, to
display DECwindows applications and programs on your workstation.
Allowing remote systems to access your account on a workstation is a security
concern. Check with your security administrator before authorizing additional hosts
to use your workstation display.
To authorize other users to use your workstation display:
1.

Select the Session Manager window.

Select the Security... option from the Customize menu. The Customize Security
box is displayed on the screen.

Customize Security

localhost

<30

no>

I*.'

i
H

Hostname(::)

Add

Type the host name you want to authorize.

6—-2 Workstation and Windowing Environments

I'I

trhost

] K| I,

Authorized hosts

Remove

Click on the Add button. The host name is added to the Authorized hosts box.

Click on either the OK or Apply button.

You can remove any host except the localhost (your workstation) from the access

control list.
To remove a host name for the current session:

Click on the name you want to remove.

Click on the Remove button.

Click on the OK button.

Users logged in to the host you remove will no longer have access to your
workstation for this session. However, the system access control list is checked each
time you start a session. If there are conflicts between the system list and your
workstation list, the system list prevails. This means that if you remove a host that
your system list allows, the host will be returned to the workstation access control
list the next time you start a session. Thus, removing a host is temporary if the host
is listed in the /etc/X* .hosts file.

Storing the Workstation Access Control List
The changes you make to your workstation access control list remain in effect only

for the current session unless you save them. You can save the changes you make
during a session from the Customize menu in the Session Manager window. When

you save the changes you make during a session, the hosts listed in the Customize

Security box are stored in a file called .Xdefaults, in your home directory. Each
time you start a new session, the workstation checks the /etc/X*.hosts system
file as well as the .Xdefaults file to determine its access control list.
Any user who can edit the

.Xdefaults file could modify the access control list

for your workstation display. If that happens, the new list of authorized hosts would
become effective the next time you start a session.

Therefore, check your file permissions. Your home directory should deny read,
write, and execute access to other, and write access to group. The permissions on the
.Xdefaults file should deny all access to group and other. Use the chmod

6.3

command to change the permissions:
chmod 750

$HOME

chmod

.Xdefaults

600

Protecting Keyboard Input
DECwindows includes a secure keyboard mode that directs everything you type on
the workstation keyboard to a single, secure window. All keyboard input is directed
to the secure window, even if you have selected another window for input focus. In

secure keyboard mode, keyboard input is read only by the application that created the
window.

Secure keyboard mode is useful for protecting sensitive information, like your
password, because it prevents users from running applications that might capture your
keystrokes. Setting secure keyboard mode in a window prevents users on hosts that
are authorized to access your workstation display from reading any keyboard input
from that window. For example, if you have a root account on your workstation,

always set secure keyboard mode before using su and typing your root password.

Workstation and Windowing Environments 6-3

If hosts are authorized to access your workstation display, users on those hosts can
still copy the contents of your display at any time. When you use the su or passwd
command and type your password, the password does not appear on the screen.

Therefore, a static copy of your display will not reveal your password. A static copy
could, however, reveal the contents of a sensitive file displayed on your screen. If
you are working on sensitive files, do not authorize any host to access your display.
You can set secure keyboard mode by selecting the Secure Keyboard item from the

Commands menu in a DECterm window.

DECterm 1

WIGEULEE

Edit

Customize

[] Secure Keyboard
Clear lines off top

Clear Display
Resize Window

Clear Communications
Reset Terminal

After you select the Secure Keyboard item, the window appears in reverse video, and
the toggle button next to the Secure Keyboard item appears highlighted to indicate
that security mode has been set.
When you change a secure window to an icon, the secure keyboard mode is turned

off. If you want security to be on, you must turn it on again when you change your

icon back to a window.
You can create only one secure window at a time. If you try to create a second
secure window, you will hear a beep, reminding you that secure keyboard mode has

been set for another window. If you hear a beep when you try to set secure keyboard
mode, but have not set that mode in any other window on your screen, some other

application must have set the mode. If this happens, check with your security
administrator to find out which application may have set this mode.

6.4

Blocking Keyboard and Mouse Information
By default, DECterm windows block keyboard and mouse information sent from
another computer. This means that users on another system cannot send simulated

keystrokes or mouse clicks to your workstation. This security feature prevents

unauthorized users from sending potentially destructive commands to your
workstation when it is idle.
The ability of a DECterm window to block information sent from another host is set
by a resource called allowSendEvents, which is set to false in the
.Xdefaults file. Each time you begin a session, DECwindows uses the values in
this file to control the appearance and other characteristics of window displays on

your workstation.

6—4 Workstation and Windowing Environments

The following example shows a line in the .Xdefaults file that sets the
allowSendEvents resource false, thus blocking users logged in to other host
systems from sending keyboard or mouse information to any window that you create.
Dxterm*allowSendEvents:

false

You should leave the allowSendEvents value set to false. This prevents
unauthorized users from sending input into your DECterm window and executing
commands under your user name.

An application that opens its own window (not a DECterm window) might not block
simulated keystrokes from your display. Therefore, if you are running such an
application, check your access control list and remove any hosts that are authorized
to access your display before working on sensitive files. If you must authorize a host
to access your display (for example, to run a remote application), remember to set
secure keyboard mode before using the passwd or su commands and typing your
password.

6.5

Locking your Workstation
In a DECwindows environment, you can pause your current session. This locks your
workstation without ending your session. Your screen is cleared, and the system
displays the Pause screen. Your can resume your session any time without having to
recreate your screen environment.
Pausing a session in this way does not completely secure a workstation because
anyone who boots the workstation into single-user mode can become the superuser.
However, pausing a session is a reasonable precaution to take when you have to
leave your workstation for a short period of time.

To put your current session on hold, choose the Pause menu item from the Session
menu. Your screen is cleared and the Continue Session box is displayed.

Your Workstation Is Paused

Password

. OK I

Clearl

To continue your session:
1.

Type your password.

Click on the OK button or press RETURN.

Once your password is verified, your session resumes.

Workstation and Windowing Environments 6-5

6.6

Physical Security
Workstations often present problems for physical security; not because they are

inherently less secure than other systems, but because workstations are typically
found in ordinary offices, not in the more easily protected environment of the
computer room.

In many cases, anyone who gains access to a workstation can easily get superuser

status on that system. One method is to simply boot the system into single user
mode.

If your office has a locking door, lock the door when you are away from your system.
You must also protect your removable media, such as tape cartridges and floppy
disks. Two steps can be taken to protect files on tape cartridges and floppy disks:
e

Compress then encrypt files with the compress and crypt commands.

Should an unauthorized person gain access to a disk, this step makes it difficult
for the data to be read.
*

6.7

Lock up all floppy disks and tape cartridges when they are not in use.

Security Summary
Workstations present some unique security considerations. Because they are

typically located in offices, rather than computer rooms, it is difficult to protect them
from unauthorized use.
Access control is the key to workstation security. A host that can access your

workstation can execute commands as you. Any user logged in to an authorized host
can access your workstation. Know which hosts are authorized to access your

workstation display.
DECwindows includes some security features that you can use to improve the
security of your workstation:
e

Set the secure keyboard mode when using the su or passwd commands and
typing your password, especially when another host is authorized to access your

workstation display.
®*

Protect your

.Xdefaults file. That file determines many window

characteristics, including blocking keyboard and mouse input from other hosts.

That file also lists the hosts that are authorized to access your workstation.
®

Check your

.Xdefaults file to make sure that the allowSendEvents

resource is set to false.
*

Be selective about the hosts you add to your access control list. If you are not
sure whether to trust a host, check with your security administrator.

Remember that a system-wide access control list may authorize a host to open a

window on your workstation, even though you have not authorized the host
access through the Customize Security menu.

6—-6 Workstation and Windowing Environments

Glossary

absolute pathname
Pathnames beginning at root (/). See also relative pathname.

absolute file permissions
Permissions that replace existing permissions. Absolute permissions

differ from relative file permissions, which add to or subtract from the
current file permissions.

accountability

Identifying and holding a user accountable for actions that create,
modify, provide access to, or disseminate information.
auditing

The chronological recording of events with security implications.

audit trail

|
The combination of all audited events.

authorization data base
The data base file /etc/auth, the optional ULTRIX ndbm(3) data
base used to store passwords and password control information.
availability
Protecting the system from denial-of-service attacks that range from

misusing system resources to crashing the system.

child process
A process created by another process using the fork () system call.

daemon
A long-lived, background process that performs a system-related service.
denial of service

The prevention of authorized access to system resources, or the delaying
of time-critical operations.
directory file

A file that contains information about other files. The structure of a
directory file is controlled by the system.
effective GID
The GID associated with the process that determines the group access

rights of the process. The effective GID is usually the real GID, but can

be changed through SGID programs and certain system calls and library

routines.

effective UID

The UID associated with the process that determines the user access

rights of the process. The effective UID is usually the real UID, but can
be changed through SUID programs and certain system calls and library
routines.
encryption

The process of transforming data to an unintelligible form in such a way
that the original data either cannot be obtained (one-way encryption) or
cannot be obtained without using the inverse decryption process (twoway encryption). The ULTRIX operating system uses one-way

encryption for passwords.
file

A collection of related records treated as a unit and referenced by an
inode.

file protection

The sum of all system processes and procedures designed to inhibit
unauthorized access, modification, or destruction of a file.
file system

An initialized partition on a disk; a collection of files.
GID

Group ID. A unique integer assigned to a set of users.
group

A set of users assigned a unique group name and GID in the file
/etc/group.

group access list

The list of group identifiers (GIDs) associated with a process. The list
includes the primary GID (from /etc/passwd) and any secondary
GIDs (from /etc/group).
hard link

A link to a file that is indistinguishable from the original directory entry
(which is itself a hard link to the inode for the file). Any changes to the
file are independent of the name used to reference the file. Hard links
cannot exist between files on different file systems. See also symbolic
link.

information security

Protecting the programs and information contained within the physical
computing environment. See also physical security.
inode

A unique number that identifies a structure containing all the information
about a file, except the file name and the actual contents of the file. Each
file has an inode associated with it. Directory entries provide a crossreference between file names and inodes.

A-2 Glossary

integrity

The assurance that information is protected against unauthorized
modification or destruction.
link

See hard link, symbolic link.
link count
The number of hard links to a file.
masquerade program

A program that pretends to be a legitimate portion of the operating
environment in order to fool an authorized user into revealing sensitive
information. For example, a program that mimics the login procedure in
an attempt to steal passwords.
mode

See permission.
ordinary file

A file whose structure and content are controlled by users.
other

The file access category a process is placed in if it fails to be identified
as either user or group.
parent process

A process that creates another process.
passphrase

A password composed of a string of words.
password

A character string that a user provides at login to validate identity as an
authorized user of the system.
password aging

The removal of a password’s effectiveness after a certain length of time.
password grabber

A type of masquerade program that mimics the login prompt and steals
passwords.
permission

For file access, the authorization for user, group, or other to read, write,
or execute the file. Also refers to setting the SUID, SGID, or sticky bits
on a file.
physical security

Protecting a computer, its related peripherals, and media from physical
attack. See also information security.

Glossary A-3

PID

Process ID. The unique identification number assigned to a process at its
creation.

pipe
A mechanism that enables communication (in one direction) between
processes.

PPID

Parent Process ID. The number associated with a process that identifies

its parent process.

primary GID

The GID associated with a user account in /etc/passwd and a
process’s group access list. See also GID, group access list, secondary

GID.
privileged process

A process whose UID is zero (UID=0).
process

The content (code) and context (environment) of an executing program.

real GID
The GID of the owner of the process.
real UID
The UID of the owner of the process.
relative pathname

A pathname that does not begin at root (/).
relative file permissions

Permissions that add to or subtract from the current file permissions.

These differ from absolute file permissions, which replace current
permissions.
root

Has three meanings: (1) The name of the user account with UID=0; (2)

the top directory (/) in the file system; and (3) the file system containing
the root directory.
secondary GID
One or more GIDs extracted from /etc/group and assigned to a
process’s group access list. See also GID, group access list, primary

GID.
secrecy

Protecting information from unauthorized disclosure.

security administrator
The person responsible for implementing and maintaining system
security.

A-4 Glossary

SGID program
A program that changes the effective GID of the invoking process to the

GID of the program.
shell

The program that acts as an interface between users and the operating
system by interpreting and executing user commands.
shell escape

The mechanism that enables a user to issue a shell command from within
a program.

shell script
An executable text file containing a series of shell commands.

socket
An endpoint for communication. For a description of the various socket
types, see socket(2) in the ULTRIX Reference Pages.

soft expiration period
An option that allows a user one chance to log in with an expired
password.

special file
A file that controls system input/output.
sticky bit

A file permission. When set on a sharable, executable file, the file will
not be removed from the swap area. When set on a directory, only file
owners, the directory owner, or the superuser can remove and rename
files in the directory.

SUID program
A program that changes the effective UID of the invoking process to the

UID of the program.
superuser

A user with access to the account whose UID=0. Typically, this account
is named root. Any process with a UID=0 is considered a privileged

process and is granted special privileges by the operating system.
symbolic link
Also called a soft link (as opposed to a hard link). Where a hard link

points directly to the inode for a file, a symbolic link is a file that
contains a pathname. Symbolic links can point to directories and to files
on other file systems.
system manager

The person responsible for installing, configuring and maintaining the

operating system and associated file systems. The manager may or may
not act as security administrator.

Glossary A-5

Trojan horse program

A program that gains access to protected information under the pretext of
performing some valid function. For example, a Trojan horse in the guise
of a text editor could secretly copy user files to its creator’s account.
trusted path

A mechanism by which a person at a terminal can communicate directly
with a valid system program.

UID
User ID. A unique integer assigned to an individual user.
user

For file permissions, the owner of the file.

A-6 Glossary

Security Summaries

This appendix contains the security summaries from Chapters 2, 3, 4, 5, and 6.

B.1

Protecting Your Account
Your account is your first line of defense:

If enabled on your system, use the Secure Attention Key to ensure that your
user name and password are passed only to the correct system programs at
login. This defeats attempts to steal this information.

Pay attention to login messages that contradict your memory of your last login

Protect your password:

attempts. Use the 1ast command to check recent logins to your account.

Pick a good one. Consider using a passphrase or a system-generated
password.

B.2

Keep it secret. Do not write it down. Do not let others see you type it.

Change it regularly.

Use different passwords for different accounts.

Lock your session whenever leaving your terminal during work hours.

Verify that you have terminated all sessions before leaving work.

Protecting Your Files and Directories
Because you control permissions on your files, understand the range of available
security options, and choose those options that best fit your security needs.
e

Know how the system assigns owners and groups to files.

Set a reasonably restrictive umask value in your shell startup files (for
example, umask 027).

Provide only the minimum file permissions required for your work. You only
ask for trouble when everyone can access your files. Use the chmod command
to modify permissions as needed.

Use the group mechanism to control file access when you need to share files
with other users.

Create separate directories for files with similar security requirements.

Use the find command to check for suspicious files and files with insecure
permissions.

Understand the interaction between certain system commands (such as mv or
cp) and file permissions and ownership.

Protect removable media. If someone copies your files into the system using the

cpio command, that user becomes the owner of your files.

Understand how links operate on files.
Encrypt extremely sensitive information.

B.3

Processes and Shells
Just as you own your files and directories, you own the processes you create. Because
processes perform actions in your behalf (and with your privileges), you should know
what rules govern a process’s ability to read your files.

Understand how the system identifies your processes, and the difference
between real and effective UIDs and GIDs.
Do not execute an unknown program. It will have your effective UID and GIDs
— and therefore your rights.

Use the ps command to keep track of your processes. This enables you to kill
any suspicious processes, and alerts you to any runaway processes that are

monopolizing system resources.

Know how SUID and SGID programs work. Be aware of the potential risks

when these mechanisms are used carelessly or when source files are poorly

protected.

startup files.

Because shell scripts must be readable by those who execute them, they are less
secure than compiled programs.

B.4

Connecting to Other Systems
Although security administrators are responsible for establishing and enforcing
network security policy, network security is everyone’s concern. You can protect
your account and files by doing the following:

Set appropriate permissions on your directories and files. For more information
on setting file permissions, see Chapter 3.
Be aware of the security policy for using your network and work closely with
your security administrator to implement that policy in your account.

Carefully control the contents of network access files, such as

.rhosts and

.netrc.

If you are capturing the session transcript into a local file, begin the capture

B-2 Security Summaries

only after completing remote login. Capture only the data you need; avoid
capturing the dialogue you used to obtain the data.

B.5

Workstation and Windowing Environments
Workstations present some unique security considerations. Because they are
typically located in offices, rather than computer rooms, it is difficult to protect them
from unauthorized use.
Access control is the key to workstation security. A host that can access your
workstation can execute commands as you. Any user logged in to an authorized host
can access your workstation. Know which hosts are authorized to access your

workstation display.

DECwindows includes some security features that you can use to improve the

security of your workstation:

Set the secure keyboard mode when use the su or passwd commands and
typing your password, especially when another host is authorized to access your
workstation display.

Protect your

.Xdefaults file. That file determines many window
characteristics, including blocking keyboard and mouse input from other hosts.

That file also lists the hosts that are authorized to access your workstation.
Check your

.Xdefaults file to make sure that the allowSendEvents

resource is set to false.
Be selective about the hosts you add to your access control list. If you are not
sure whether to trust a host, check with your security administrator.

Remember that a system-wide access control list may authorize a host to open a
window on your workstation, even though you have not authorized the host
access through the Customize Security menu.

Security Summaries B-3

Index

chgrp command, 3-8

absolute file permissions, 3—6
absolute pathnames, 4-9

access control lists
See DECwindows access control lists
accountability, 1-2

allowSendEvents
DECwindows resource, 64
anonymous account

ftp provides no audit trail, 54
ar command

file permissions needed to execute, 3-11
audit log, 2-3

auditing
anonymous ftp provides no audit trail, 54
failed logins in /usr/spool/mqueue/syslog, 2—3

recent logins in /usr/adm/wtmp, 2-3
authorization data base
See /etc/auth

availability, 1-2

control file access with, 3-9
child process
See process
chmod command
accepts octal and symbolic values, 3—6

comparison with umask command, 3-3
description of, 3-6
interaction with umask, 3—7
octal example of, 3-6, 5-3

symbolic example of, 3-6
chown command
only superuser can execute, 3-2

clear command, 2-7
compress command

protecting removable media, 6-6
cp command

affects file permissions, 3—13
affects SUID/SGID programs, 4-8
file permissions needed to execute, 3-11
cpio command

affects file permissions, 3—13
file permissions needed to execute, 3—11
Bourne shell, 4-9

crypt command, 3-14