Practical UNIX & Internet Security phần 8 pdf

D.1.6 Cryptography Papers and Other Publications
Association for Computing Machinery. "Codes, Keys, and Conflicts: Issues in U.S. Crypto Policy."
Report of a Special Panel of the ACM U.S. Public Policy Committee location: USACM, June 1994.
(URL: />Coppersmith, Don. IBM Journal of Research and Development 38 (1994).
Diffie, Whitfield. "The First Ten Years of Public-Key Cryptography." Proceedings of the IEEE 76
(1988): 560-76. Whitfield Diffie's tour-de-force history of public key cryptography, with revealing
commentaries.
Diffie, Whitfield, and M.E. Hellman. "New Directions in Cryptography." IEEE Transactions on
Information Theory IT-22 (1976). The article that introduced the concept of public key cryptography.
Hoffman, Lance J., Faraz A. Ali, Heckler, Steven L. and Ann Huybrechts. "Cryptography Policy."
Communications of the ACM 37 (1994): 109-17.
Lai, Xuejia. "On the Design and Security of Block Ciphers." ETH Series in Information Processing 1
(1992). The article describing the IDEA cipher.
Lai, Xuejia, and James L. Massey. "A Proposal for a New Block Encryption Standard." Advances in
Cryptology-EUROCRYPT '90 Proceedings (1992): 55-70. Another article describing the IDEA cipher.
LaMacchia, Brian A. and Andrew M. Odlyzko. "Computation of Discrete Logarithms in Prime Fields."
Designs, Codes, and Cryptography. (1991):, 46-62.
Lenstra, A.K., H. W. Lenstra, Jr., M.S. Manasse, and J.M. Pollard. "The Number Field Sieve."
Proceedings of the 22nd ACM Symposium on the Theory of Computing. Baltimore MD: ACM Press,
1990, 564-72.
Lenstra, A.K., Lenstra, Jr., H.W., Manasse, M.S., and J.M. Pollard. "The Factorization of the Ninth
Fermat Number." Mathematics of Computation 61 (1993): 319-50.
Merkle, Ralph. "Secure Communication Over Insecure Channels." Communications of the ACM 21
(1978): 294-99 (submitted in 1975). The article that should have introduced the concept of public key
cryptography.
Merkle, Ralph, and Martin E. Hellman. "On the Security of Multiple Encryption." Communications of
the ACM 24 (1981): 465-67.
Merkle, Ralph, and Martin E. Hellman. "Hiding Information and Signatures in Trap Door Knapsacks."
IEEE Transactions on Information Theory 24 (1978): 525-30.
National Bureau of Standards. Data Encryption Standard 1987.(FIPS PUB 46-1)
Rivest, Ron. Ciphertext: The RSA Newsletter 1 (1993).

Rivest, Ron, A. Shamir, and L. Adleman. "A Method for Obtaining Digital Signatures and Public Key
Cryptosystems." Communications of the ACM 21 (1978).
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (5 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
Simmons, G. J. "How to Insure that Data Acquired to Verify Treaty Compliance are Trustworthy." in
"Authentication without secrecy: A secure communications problem uniquely solvable by asymmetric
encryption techniques." IEEE EASCON '79, (1979): 661-62.
D.1.7 General Computer Security
Amoroso, Edward. Fundamentals of Computer Security Technology. Englewood Cliffs, NJ:
Prentice-Hall, 1994. A very readable and complete introduction to computer security at the level of a
college text.
Carroll, John M. Computer Security. 2nd edition, Stoneham, MA: Butterworth Publishers, 1987.
Contains an excellent treatment of issues in physical communications security.
Computers & Security. This is a journal published eight times each year by Elsevier Press, Oxford,
England. (Order from Elsevier Press, +44-(0) 865-512242.) It is one of the main journals in the field.
This journal is priced for institutional subscriptions, not individuals. Each issue contains pointers to
dozens of other publications and organizations that might be of interest, as well as referenced articles,
practicums, and correspondence. The URL for the WWW page is included in "Security Periodicals."
Computer Security Requirements - Guidance for Applying the Department of Defense Trusted Computer
System Evaluation Criteria in Specific Environments, Fort George G. Meade, MD: National Computer
Security Center, 1985. (Order number CSC-STD-003-85.) (The Yellow Book)
Datapro Reports on Computer Security. Delran, NJ: McGraw-Hill. (Order from Datapro, 609-764-0100.)
An ongoing (and expensive) series of reports on various issues of security, including legislation trends,
new products, items in the news, and more. Practitioners are divided on the value of this publication, so
check it out carefully before you buy it to see if it is useful in your situation.
Department of Defense Password Management Guideline. Fort George G. Meade, MD: National
Computer Security Center, 1985. (Order number CSC-STD-002-85.) (The Green Book)
Department of Defense Trusted Computer System Evaluation Criteria. Fort George G. Meade, MD:
National Computer Security Center, 1985. (Order number DoD 5200.28-STD.) (The Orange Book)

Fites, P. E., M. P. J. Kratz, and A. F. Brebner. Control and Security of Computer Information Systems.
Rockville, MD: Computer Science Press, 1989. A good introduction to the administration of security
policy and not techniques.
Gasser, Morrie. Building a Secure Computer System. New York, NY: Van Nostrand Reinhold, 1988. A
solid introduction to issues of secure system design.
Hunt, A. E., S. Bosworth, and D. B. Hoyt, eds. Computer Security Handbook, 3rd edition. New York,
NY: Wiley, 1995. A massive and thorough collection of essays on all aspects of computer security.
National Research Council, Computers at Risk: Safe Computing in the Information Age. Washington,
DC: National Academy Press, 1991. (Order from NRC, 1-800-624-6242.) This book created considerable
comment. It's a report of a panel of experts discussing the need for national concern and research in the
areas of computer security and privacy. Some people think it is a significant publication, while others
believe it has faulty assumptions and conclusions. Either way, you should probably read it.
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (6 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
Pfleeger, Charles P. Security in Computing. Englewood Cliffs, NJ: Prentice-Hall, 1989. Another good
introduction to computer security.
Russell, Deborah, and G. T. Gangemi, Sr. Computer Security Basics. Sebastopol, CA: O'Reilly &
Associates, 1991. An excellent introduction to many areas of computer security and a summary of
government security requirements and issues.
Thompson, Ken. "Reflections on Trusting Trust" Communications of the ACM, Volume 27, Number 8,
August (1984). This is a "must-read" for anyone seeking to understand the limits of computer security
and trust.
Wood, Charles Cresson, et al. Computer Security: A Comprehensive Controls Checklist, New York, NY:
John Wiley & Sons, 1987. Contains many comprehensive and detailed checklists for assessing the state
of your own computer security and operations.
Wood, Charles Cresson. Information Security Policies Made Easy. Sausalito, CA: Baseline Software,
1994. This book and accompanying software allow the reader to construct a corporate security policy
using hundreds of components listed in the book. Pricey, but worth it if you need to write a
comprehensive policy:

Baseline Software
PO Box 1219
Sausalito, CA 94966-1219
++1 415-332-7763
D.1.8 Network Technology and Security
Bellovin, Steve and Cheswick, Bill. Firewalls and Internet Security. Reading, MA: Addison-Wesley,
1994. The classic book on firewalls. This book will teach you everything you need to know about how
firewalls work, but it will leave you without implementation details unless you happen to have access to
the full source code to the UNIX operating system and a staff of programmers who can write bug-free
code.
Chapman, D. Brent, and Elizabeth D. Zwicky. Building Internet Firewalls. Sebastopol, CA: O'Reilly &
Associates, 1995. A good how-to book that describes in clear detail how to build your own firewall.
Comer, Douglas E. Internetworking with TCP/IP. 3rd Edition. Englewood Cliffs, NJ: Prentice Hall,
1995. A complete, readable reference that describes how TCP/IP networking works, including
information on protocols, tuning, and applications.
Frey, Donnalyn, and Rick Adams. !%@:: A Directory of Electronic Mail Addressing and Networks,
Sebastopol, CA: O'Reilly & Associates, 1990. This guide is a complete reference to everything you
would ever want to know about sending electronic mail. It covers addressing and transport issues for
almost every known network, along with lots of other useful information to help you get mail from here
to there. Highly recommended.
Hunt, Craig. TCP/IP Network Administration. Sebastopol, CA: O'Reilly & Associates, 1992. This book
is an excellent system administrator"s overview of TCP/IP networking (with a focus on UNIX systems),
and a very useful reference to major UNIX networking services and tools such as BIND (the standard
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (7 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
UNIX DNS Server) and sendmail (the standard UNIX SMTP Server).
Kaufman, Charles, Radia Perlman, and Mike Speciner. Network Security: Private Communications in a
Public World. Englewood Cliffs, NJ: Prentice-Hall, 1995.
Liu, Cricket, Jerry Peek, Russ Jones, Bryan Buus, and Adrian Nye. Managing Internet Information

Services, Sebastopol, CA: O'Reilly & Associates, 1994. This is an excellent guide to setting up and
managing Internet services such as the World Wide Web, FTP, Gopher, and more, including discussions
of the security implications of these services.
Stallings, William. Network and Internetwork Security: Principles and Practice. Englewood Cliffs, NJ:
Prentice Hall, 1995. A good introductory textbook.
Stevens, Richard W. TCP/IP Illustrated. The Protocols, Volume 1. Reading, MA: Addison-Wesley,
1994. This is a good guide to the nuts and bolts of TCP/IP networking. Its main strength is that it
provides traces of the packets going back and forth as the protocols are actually in use, and uses the
traces to illustrate the discussions of the protocols.
Quarterman, John. The Matrix: Computer Networks and Conferencing Systems Worldwide. Bedford,
MA: Digital Press, 1990. A dated but still insightful book describing the networks, protocols, and politics
of the world of networking.
D.1.9 Security Products and Services Information
Computer Security Buyer's Guide. Computer Security Institute, San Francisco, CA. (Order from CSI,
415-905-2626.) Contains a comprehensive list of computer security hardware devices and software
systems that are commercially available. The guide is free with membership in the Institute. The URL is
at .
D.1.10 Understanding the Computer Security "Culture"
All of these describe views of the future and computer networks that are much discussed (and emulated)
by system crackers.
Brunner, John. Shockwave Rider. New York, NY: A Del Ray Book, published by Ballantine, 1975. One
of the first descriptions of a computer worm.
Gibson, William. Burning Chrome, Count Zero, Mona Lisa Overdrive, and Neuromancer New York,
NY: Bantam Books These four cyberpunk books by the science fiction author who coined the term
"cyberspace."
Hafner, Katie and John Markoff, Cyberpunk: Outlaws and Hackers on the Computer Frontier. New
York, NY: Simon and Schuster, 1991. Tells the stories of three hackers - Kevin Mitrick, Pengo, and
Robert T. Morris.
Levy, Steven. Hackers: Heroes of the Computer Revolution. New York, NY: Dell Books, 1984. One of
the original publications describing the "hacker ethic."

Littman, Jonathan, The Fugitive Game: Online with Kevin Mitnick. Boston, MA: Little, Brown, 1996. A
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (8 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
year prior to his capture in 1995, Jonathan Littman had extensive telephone conversations with Kevin
Mitnick and learned what it is like to be a computer hacker on the run. This is the story.
Shimomura, Tsutomu, with John Markoff. Takedown: The Pursuit and Capture of Kevin Mitnick,
America's Most Wanted Computer Outlaw By the Man Who Did it. New York, NY: Hyperion, 1995.
On Christmas Day, 1994, an attacker broke into Tsutomu Shimomura's computer. A few weeks later,
Shimomura was asked to help out with a series of break-ins at two major Internet service providers in the
San Fransisco area. Eventually, the trail led to North Carolina, where Shimomura participated in the
tracking and capture of Kevin Mitnick. This is the story, written by Shimomura and Markoff. Markoff is
the journalist with The New York Times who covered the capture.
Sterling, Bruce. The Hacker Crackdown: Law and Disorder on the Electronic Frontier. This book is
available in several places on the WWW; is one
location; other locations can be found in the COAST hotlist.
Stoll, Cliff. The Cuckoo's Egg, Garden City, NY: Doubleday, 1989. An amusing and gripping account of
tracing a computer intruder through the networks. The intruder was later found to be working for the
KGB and trying to steal sensitive information from U.S. systems.
Varley, John. Press Enter. Reprinted in several collections of science fiction, including Blue Champagne,
Ace Books, 1986; Isaac Asimov's Science Fiction Magazine, 1984; and Tor SF Doubles, October, Tor
Books, 1990.
Vinge, Vernor. True Names and Other Dangers. New York, NY: Baen, distributed by Simon & Schuster,
1987.
D.1.11 UNIX Programming and System Administration
Albitz, Paul and Cricket Liu. DNS and BIND. Sebastopol, CA: O'Reilly & Associates, 1992. An
excellent reference for setting up DNS nameservers.
Bach, Maurice. The Design of the UNIX Operating System. Englewood Cliffs, NJ: Prentice-Hall, 1986.
Good background about how the internals of UNIX work. Basically oriented toward older System V
UNIX, but with details applicable to every version.

Bolsky, Morris I., and David G. Korn. The New Kornshell Command and Programming Language.
Englewood Cliffs, NJ: Prentice-Hall, 1995. This is a complete tutorial and reference to the 1992 ksh - the
only shell some of us use when given the choice.
Costales, Bryan, with Eric Allman and Neil Rickert. sendmail. Sebastopol, CA: O'Reilly & Associates,
1993. Rightly or wrongly, many UNIX sites continue to use the sendmail mail program. This huge book
will give you tips on configuring it more securely.
Goodheart, B. and J. Cox. The Magic Garden Explained: The Internals of UNIX SVR4. Englewood
Cliffs, N.J.: Prentice-Hall, 1994
Harbison, Samuel P. and Guy L. Steele Jr., C, a Reference Manual. Englewood Cliffs, NJ: Prentice Hall,
1984.
Hu, Wei. DCE Security Programming. Sebastopol, CA: O'Reilly & Associates, 1995.
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (9 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
Kernighan, Brian, Dennis Ritchie and Rob Pike. The UNIX Programming Environment. Englewood
Cliffs, NJ: Prentice-Hall, 1984. A nice guide to the UNIX philosophy and how to build shell scripts and
command environments under UNIX.
Leffler, Samuel, Marshall Kirk McKusick, Michael Karels, and John Quarterman. The Design and
Implementation of the 4.3 BSD UNIX Operating System. Reading, MA: Addison Wesley, 1989. This
book can be viewed as the BSD version of Maurice Bach's book. It is a readable and detailed description
of how and why the BSD UNIX system is designed the way it is. (An updated version covering BSD 4.4
is rumored to be in production, to appear after publication of this edition.)
Nemeth, Evi, Garth Snyder, Scott Seebass, and Trent R. Hein. UNIX System Administration Handbook.
2nd Edition. Englewood Cliffs, NJ: Prentice-Hall, 1995. An excellent reference on the various ins and
outs of running a UNIX system. This book includes information on system configuration, adding and
deleting users, running accounting, performing backups, configuring networks, running sendmail, and
much more. Highly recommended.
O'Reilly, Tim, and Grace Todino. Managing UUCP and Usenet. Sebastopol CA: O'Reilly & Associates,
1992. If you run UUCP on your machine, you need this book. It discusses all the various intricacies of
running the various versions of UUCP. Included is material on setup and configuration, debugging

connections, and accounting. Highly recommended.
Peek, Jerry et al. UNIX Power Tools, Sebastopol, CA: O'Reilly & Associates, 1993.
Ramsey, Rick. All About Administering NIS+. Englewood Cliffs, NJ: Prentice-Hall, 1994.
Rochkind, Marc. Advanced UNIX Programming. Englewood Cliffs, NJ: Prentice-Hall, 1985. This book
has easy-to-follow introduction to various system calls in UNIX (primarily System V) and explains how
to use them from C programs. If you are administering a system and reading or writing system-level
code, this book is a good way to get started, but keep in mind that this is rather dated.
Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, MA:
Addison-Wesley, 1992.
D.1.12 Miscellaneous References
Hawking, Stephen W. A Brief History of Time: From the Big Bang to Black Holes, New York, NY:
Bantam Books, 1988. Want to find the age of the universe? It's in here, but UNIX is not.
Miller, Barton P., Lars Fredriksen, and Bryan So. "An Empirical Study of the Reliability of UNIX
Utilities," Communications of the ACM, Volume 33, Number 12, December 1990, 32-44. A
thought-provoking report of a study showing how UNIX utilities behave when given unexpected input.
Wall, Larry, and Randal L. Schwartz. Programming perl, Sebastopol, CA: O'Reilly & Associates, 1991.
The definitive reference to the Perl scripting language. A must for anyone who does much shell, awk, or
sed programming or would like to quickly write some applications in UNIX.
Wall, Larry and Randal L. Schwartz. Learning perl, Sebastopol, CA: O'Reilly & Associates, 1993.
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (10 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
C.5 Starting Up UNIX and
Logging In
D.2 Security Periodicals
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Appendix D] Paper Sources
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appd_01.htm (11 of 11) [2002-04-12 10:45:18]
Simpo PDF Merge and Split Unregistered Version -
Appendix C

C. UNIX Processes
Contents:
About Processes
Creating Processes
Signals
The kill Command
Starting Up UNIX and Logging In
This appendix provides technical background on how the UNIXoperating system manages processes. The information presented in
this chapter is important to understand if you are concerned with the details of system administration or are simply interested in
UNIX internals, but we felt that it was too technical to present early in this book.
C.1 About Processes
UNIX is a multitasking operating system. Every task that the computer is performing at any moment - every user running a word
processor program, for example - has a process. The process is the operating system's fundamental tool for controlling the computer.
Nearly everything that UNIX does is done with a process. One process displays the word login: on the user's terminal and reads the
characters that the user types to log into the system. Another process controls the line printer. On a workstation, a special process
called the "window server" displays text in windows on the screen. Another process called the "window manager" lets the user move
those windows around.
At any given moment, the average UNIX operating system might be running anywhere from ten to several hundred different
processes; large mainframes might be running several thousand. UNIX runs at least one process for every user who is logged in,
another process for every program that every user is running, and another process for every hard-wired terminal that is waiting for a
new user to log in. UNIX also uses a variety of special processes for system functions.
C.1.1 Processes and Programs
A process is an abstraction of control that has certain special properties associated with it. These include a private stack, values of
registers, a program counter, an address space containing program code and data, and so on. The underlying hardware and operating
system software manage the contents of registers in such a way that each process views the computer's resources as its "own" while it
is running. With a single processor, only one process at a time is actually running, with the operating system swapping processes
from time to time to give the illusion that they are all running concurrently. Multi-processor computers can naturally run several
processes with true synchronicity.
Every UNIX process has a program that it is running, even if that program is part of the UNIX operating system (a special program).

Programs are usually referred to by the names of the files in which they are kept. For example, the program that lists files is called
/bin/ls and the program that runs the line printer may be called /usr/lib/lpd.
A process can run a program that is not stored in a file in either of two ways:
The program's file can be deleted after its process starts up. In this case, the process's program is really stored in a file, but the
file no longer has a name and cannot be accessed by any other processes. The file is deleted automatically when the process
exits or runs another program.
●
The process may have been specially created in the computer's memory. This is the method that the UNIX kernel uses to begin
the first process when the operating system starts up. This usually happens only at start-up, but some programming languages
●
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (1 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
such as LISP can load additional object modules as they are running.
Normally, processes run a single program and then exit. However, a program can cause another program to be run. In this case, the
same process starts running another program.
C.1.2 The ps Command
The ps command gives you a snapshot of all of the processes running at any given moment. ps tells you who is running programs on
your system, as well as which programs the operating system is spending its time executing.
Most system administrators routinely use the ps command to see why their computers are running so slowly; system administrators
should also regularly use the command to look for suspicious processes. (Suspicious processes are any processes that you don't
expect to be running. Methods of identifying suspicious processes are described in detail in earlier chapters.)
C.1.2.1 Listing processes with systems derived from System V
The System V ps command will normally only print the processes that are associated with the terminal on which the program is being
run. To list all of the processes that are running on your computer, you must run the program with the -ef options. The options are:
Option Effect
e List all processes
f Produce a full listing
For example:
sun.vineyard.net% /bin/ps -ef

UID PID PPID C STIME TTY TIME COMD
root 0 0 64 Nov 16 ? 0:01 sched
root 1 0 80 Nov 16 ? 9:56 /etc/init -
root 2 0 80 Nov 16 ? 0:10 pageout
root 3 0 80 Nov 16 ? 78:20 fsflush
root 227 1 24 Nov 16 ? 0:00 /usr/lib/saf/sac -t 300
root 269 1 18 Nov 16 console 0:00 /usr/lib/saf/ttymon -g - root 97
1 80 Nov 16 ? 1:02 /usr/sbin/rpcbind
root 208 1 80 Nov 16 ? 0:01 /usr/dt/bin/dtlogin
root 99 1 21 Nov 16 ? 0:00 /usr/sbin/keyserv
root 117 1 12 Nov 16 ? 0:00 /usr/lib/nfs/statd
root 105 1 12 Nov 16 ? 0:00 /usr/sbin/kerbd
root 119 1 27 Nov 16 ? 0:00 /usr/lib/nfs/lockd
root 138 1 12 Nov 16 ? 0:00 /usr/lib/autofs/automoun root 162
1 62 Nov 16 ? 0:01 /usr/lib/lpsched
root 142 1 41 Nov 16 ? 0:00 /usr/sbin/syslogd
root 152 1 80 Nov 16 ? 0:07 /usr/sbin/cron
root 169 162 8 Nov 16 ? 0:00 lpNet
root 172 1 80 Nov 16 ? 0:02 /usr/lib/sendmail -q1h
root 199 1 80 Nov 16 ? 0:02 /usr/sbin/vold
root 180 1 80 Nov 16 ? 0:04 /usr/lib/utmpd
root 234 227 31 Nov 16 ? 0:00 /usr/lib/saf/listen tcp
simsong 14670 14563 13 12:22:12 pts/11 0:00 rlogin next
root 235 227 45 Nov 16 ? 0:00 /usr/lib/saf/ttymon
simsong 14673 14535 34 12:23:06 pts/5 0:00 rlogin next
simsong 14509 1 80 11:32:43 ? 0:05 /usr/dt/bin/dsdm
simsong 14528 14520 80 11:32:51 ? 0:18 dtwm
simsong 14535 14533 66 11:33:04 pts/5 0:01 /usr/local/bin/tcsh
simsong 14529 14520 80 11:32:56 ? 0:03 dtfile -session dta003TF
root 14467 1 11 11:32:23 ? 0:00 /usr/openwin/bin/fbconso simsong 14635

14533 80 11:48:18 pts/12 0:01 /usr/local/bin/tcsh
simsong 14728 14727 65 15:29:20 pts/9 0:01 rlogin next
root 332 114 80 Nov 16 ? 0:02 /usr/dt/bin/rpc.ttdbserv root 14086
208 80 Dec 01 ? 8:26 /usr/openwin/bin/Xsun :0 simsong 13121 13098 80 Nov
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (2 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
29 pts/6 0:01 /usr/local/bin/tcsh
simsong 15074 14635 20 10:48:34 pts/12 0:00 /bin/ps -ef
Table 27.2 describes the meaning of each field in this output.
Field in ps Output (System V)
Table C.1: Feild in ps Output (System V)
Field Meaning
UID The username of the person running the command
PID The process's identification number (see next section)
PPID The process ID of the process's parent process
C The processor utilization; an indication of how much CPU time the process is using at the moment
STIME The time that the process started executing
TTY The controlling terminal for the process
TIME The total amount of CPU time that the process has used
COMD The command that was used to start the process
C.1.2.2 Listing processes with Berkeley-derived versions of UNIX
With Berkeley UNIX, you can use the command:
% ps -auxww
to display detailed information about every process running on your computer. The options specified in this command are:
Option Effect
a List all processes
u Display the information in a user-oriented style
x Include information on processes that do not have controlling ttys
ww Include the complete command lines, even if they run past 132 columns

For example:[1]
[1] Many Berkeley-derived versions also show a start time (START) between STAT and TIME.
% ps -auxww
USER PID %CPU %MEM SZ RSS TT STAT TIME COMMAND
simsong 1996 62.6 0.6 1136 1000 q8 R 0:02 ps auxww
root 111 0.0 0.0 32 16 ? I 1:10 /etc/biod 4
daemon 115 0.0 0.1 164 148 ? S 2:06 /etc/syslog
root 103 0.0 0.1 140 116 ? I 0:44 /etc/portmap
root 116 0.0 0.5 860 832 ? I 12:24 /etc/mountd -i -s
root 191 0.0 0.2 384 352 ? I 0:30 /usr/etc/bin/lpd
root 73 0.0 0.3 528 484 ? S < 7:31 /usr/etc/ntpd -n
root 4 0.0 0.0 0 0 ? I 0:00 tpathd
root 3 0.0 0.0 0 0 ? R 0:00 idleproc
root 2 0.0 0.0 4096 0 ? D 0:00 pagedaemon
root 239 0.0 0.1 180 156 co I 0:00 std.9600 console
root 0 0.0 0.0 0 0 ? D 0:08 swapper
root 178 0.0 0.3 700 616 ? I 6:31 /etc/snmpd
root 174 0.0 0.1 184 148 ? S 5:06 /etc/inetd
root 168 0.0 0.0 56 44 ? I 0:16 /etc/cron
root 132 0.0 0.2 452 352 co I 0:11 /usr/etc/lockd
jdavis 383 0.0 0.1 176 96 p0 I 0:03 rlogin hymie
ishii 1985 0.0 0.1 284 152 q1 S 0:00 /usr/ucb/mail bl
root 26795 0.0 0.1 128 92 ? S 0:00 timed
root 25728 0.0 0.0 136 56 t3 I 0:00 telnetd
jdavis 359 0.0 0.1 540 212 p0 I 0:00 -tcsh (tcsh)
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (3 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
root 205 0.0 0.1 216 168 ? I 0:04 /usr/local/cap/atis
kkarahal 16296 0.0 0.4 1144 640 ? I 0:00 emacs

root 358 0.0 0.0 120 44 p0 I 0:03 rlogind
root 26568 0.0 0.0 0 0 ? Z 0:00 <exiting>
root 10862 0.0 0.1 376 112 ? I 0:00 rshd
The fields in this output are described in Table 27.3. Individual STAT characters are described in Tables C-3, C-4, and C-5.
Table C.2: Fields in ps Output (Berkeley-derived)
Field Meaning
USER The username of the process. If the process has a UID (described in the next section) that does not appear in
/etc/passwd, the UID is printed instead.[2]
PID The process's identification number
%CPU, %MEM The percentage of the system's CPU and memory that the process is using
SZ The amount of virtual memory that the process is using
RSS The resident set size of the process - the amount of physical memory that the process is occupying
TT The terminal that is controlling the process
STAT A field denoting the status of the process; up to three letters (four under SunOS) are shown
TIME CPU time used by the process
COMMAND The name of the command (and arguments)
[2] If this happens, follow up to be sure you don't have an intruder.
Table C.3: . Runnability of Process
(First Letter of STAT Field)
Letter Meaning
R Actually running or runnable
S Sleeping (sleeping > 20 seconds)
I Idle (sleeping < 20 seconds)
T Stopped
H Halted
P In page wait
D In disk wait
Z Zombie
Table C.4: . Whether Process Swapped (Second Letter of STAT Field)
Letter Meaning

<Blank> In core
W Swapped out
> A process that has exceeded a soft limit on memory requirements
Table C.5: . Whether Process Is running with
Altered CPU Schedule (Third Letter of STAT
Field)
Letter Meaning
N The process is running at a low priority
# nice (a number greater than 0).
< The process is running at a high priority.
NOTE: Because command arguments are stored in the process's own memory space, a process can change what appears
on its command line. If you suspect that a process may not be what it claims to be, type:
% ps -c
This causes ps to print the name of the command stored in the kernel. This approach is substantially faster than the standard ps, and is
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (4 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
more suitable for use with scripts that run periodically. Unfortunately, the ps -c display does not include the arguments of each
command that is running.
C.1.3 Process Properties
The kernel maintains a set of properties for every UNIX process. Most of these properties are denoted by numbers. Some of these
numbers refer to processes, while others determine what privileges the processes have.
C.1.3.1 Process identification numbers (PID)
Every process is assigned a unique number called the process identifier, or PID. The first process to run, called init, is given the
number 1. Process numbers can range from 1 to 65535.[3] When the kernel runs out of process numbers, it recycles them. The kernel
guarantees that no two active processes will ever have the same number.
[3] Some versions of UNIX may allow process numbers in a range different from 1 to 65535.
C.1.3.2 Process real and effective UID
Every UNIX process has two user identifiers: a real UID and an effective UID.
The real UID (RUID) is the actual user identifier (UID) of the person who is running the program. It is usually the same as the UID

of the actual person who is logged into the computer, sitting in front of the terminal (or workstation).
The effective UID (EUID) identifies the actual privileges of the process that is running.
Normally, the real UID and the effective UID are the same. That is, normally you have only the privileges associated with your own
UID. Sometimes, however, the real and effective UID can be different. This occurs when a user runs a special kind of program,
called a SUID program, which is used to accomplish a specific function (such as changing the user's password). SUID programs are
described in Chapter 4, Users, Groups, and the Superuser.
C.1.3.3 Process priority and niceness
Although UNIX is a multitasking operating system, most computers that run UNIX can run only a single process at a time.[4] Every
fraction of a second, the UNIX operating system rapidly switches between many different processes, so that each one gets a little bit
of work done within a given amount of time. A tiny but important part of the UNIX kernel called the process scheduler decides
which process is allowed to run at any given moment and how much CPU time that process should get.
[4] Multiprocessor computers can run as many processes at a time as they have processors.
To calculate which process it should run next, the scheduler computes the priority of every process. The process with the lowest
priority number (or the highest priority) runs. A process's priority is determined with a complex formula that includes what the
process is doing and how much CPU time the process has already consumed. A special number, called the nice number or simply the
nice, biases this calculation: the lower a process's nice number, the higher its priority, and the more likely that it will be run.
On most versions of UNIX, nice numbers are limited from -20 to +20. Most processes have a nice of 0. A process with a nice number
of +19 will probably not run until the system is almost completely idle; likewise, a process with a nice number of -19 will probably
preempt every other user process on the system.
Sometimes you will want to make a process run slower. In some cases, processes take more than their "fair share" of the CPU, but
you don't want to kill them outright. An example is a program that a researcher has left running overnight to perform mathematical
calculations that isn't finished the next morning. In this case, rather than killing the process and forcing the researcher to restart it
later from the beginning, you could simply cut the amount of CPU time that the process is getting and let it finish slowly during the
day. The program /etc/renice lets you change a process's niceness.
For example, suppose that Mike left a program running before he went home. Now it's late at night, and Mike's program is taking up
most of the computer's CPU time:
% ps aux | head -5
USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND
mike 211 70.0 6.7 2.26M 1.08M 01 R 4:01 cruncher
mike 129 8.2 15.1 7.06M 2.41M 01 S 0:48 csh

donna 212 7.0 7.3 2.56M 1.16M p1 S 1:38 csh
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (5 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
michelle 290 4.0 11.9 14.4M 1.91M 03 R 19:00 rogue %
You could slow down Mike's program by renicing it to a higher nice number.
For security reasons, normal users are only allowed to increase the nice numbers of their own processes. Only the superuser can
lower the nice number of a process or raise the nice number of somebody else's process. (Fortunately, in this example, we know the
superuser password!)
% /bin/su
password: another39
# /etc/renice +4 211
211: old priority 0, new priority 4
# ps u211
USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND
mike 211 1.5 6.7 2.26M 1.08M 01 R N 4:02 cruncher
The N in the STAT field indicates that the cruncher process is now running at a lower priority (it is "niced"). Notice that the process's
CPU consumption has already decreased. Any new processes that are spawned by the process with PID 211 will inherit this new nice
value, too.
You can also use /etc/renice to lower the nice number of a process to make it finish faster.[5] Although setting a process to a lower
priority won't speed up the CPU or make your computer's hard disk transfer data faster, the negative nice number will cause UNIX to
run a particular process more than it runs others on the system. Of course, if you ran every process with the same negative priority,
there wouldn't be any apparent benefit.
[5] Only root can renice a process to make it faster. Normal processes can't even change themselves back to what they
were (if they've been niced down). Normal users can't even raise the priority of their processes to the value at which they
were started.
Some versions of the renice command allow you to change the nice of all processes belonging to a user or all processes in a process
group (described in the next section). For instance, to speed up all of Mike's processes, you might type:
# renice -2 -u mike
Remember, processes with a lower nice number run faster.

Note that because of the UNIX scheduling system, renicing several processes to lower numbers is likely to increase paging activity if
there is limited physical memory, and therefore adversely impact overall system performance.
What do process priority and niceness have to do with security? If an intruder has broken into your system and you have contacted
the authorities and are tracing the phone call, slowing the intruder down with a priority of +10 or +15 will limit the damage that the
intruder can do without hanging up the phone (and losing your chance to catch the intruder). Of course, any time that an intruder is
on a system, exercise extreme caution.
Also, running your own shell with a higher priority may give you an advantage if the system is heavily loaded. The easiest way to do
so is by typing:
# renice -5 $$
The shell will replace the $$ with the PID of the shell's process.
C.1.3.4 Process groups and sessions
With Berkeley-derived versions of UNIX, including SVR4, each process is assigned a process ID (PID), a process group ID, and a
session ID. Process groups and sessions are used to implement job control.
For each process, the PID is a unique number, the process group ID is the PID of the process group leader process, and the session ID
is the PID of the session leader process. When a process is created, it inherits the process group ID and the session ID of its parent
process. Any process may create a new process group by calling setpgrp() and may create a new session by calling the UNIX system
call setsid(). All processes that have the same process group ID are said to be in the same process group.
Each UNIX process group belongs to a session group. This is used to help manage signals and orphaned processes. Once a user has
logged in, the user may start multiple sets of processes, or jobs, using the shell's job-control mechanism. A job may have a single
process, such as a single invocation of the ls command. Alternatively, a job may have several processes, such as a complex shell
pipeline. For each of these jobs, there is a process group. UNIX also keeps track of the particular process group which is controlling
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (6 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
the terminal. This can be set or changed with ioctl() system calls. Only the controlling process group can read or write to the terminal.
A process could become an orphan if its parent process exits but it continues to run. Historically, these processes would be inherited
by the init process but would remain in their original process group. If a signal were sent by the controlling terminal (process group),
then it would go to the orphaned process, even though it no longer had any real connection to the terminal or the rest of the process
group.
To counter this, POSIX defines an orphaned process group. This is a process group where the parent of every member is either not a

member of the process group's session, or is itself a member of the same process group. Orphaned process groups are not sent
terminal signals when they are generated. Because of the way in which new sessions are created, the initial process in the first
process group is always an orphan (its ancestor is not in the session). Command interpreters are usually spawned as session leaders so
they ignore TSTP signals from the terminal.
B.3 SUID and SGID Files C.2 Creating Processes
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Appendix C] UNIX Processes
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appc_01.htm (7 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
Appendix B
Important Files

B.3 SUID and SGID Files
To run a secure computer, you must know of every SUID and SGID file on the system and be sure that each file has the
proper permissions for which it was designed.
Unfortunately, there is a huge amount of variation among UNIX vendors in the use of SUID and SGID. Some manufacturers
use SUID root for all privilege-requiring programs, while some create special groups for controlling terminals (group tty), or
disks (group operator), or memory (group kmem). Some vendors use a variety of approaches. Most change their approaches
to SUID and SGID from software release to software release. As a result, any attempt to list SUID and SGID files on a
system that is not constrained to a particular release is likely to be incomplete.
You may also receive SUID or SGID files as part of third-party software that you may purchase or download from the net.
Many of these third-party programs require SUID root permission because they modify devices or do things on behalf of
users. If you choose to use these programs, you should seek assurance from the vendor that superuser privileges are confined
to the smallest possible region of the program, and that, in general, rules such as those contained in Chapter 23, Writing
Secure SUID and Network Programs, have been followed in coding the software. You may also wish to obtain written
representations from the vendor that the security of the computer system will not be compromised as a result of SUID/SGID
programs, and that, in the event that the system is compromised, the vendor will pay for damages.
B.3.1 SUID/SGID Files in Solaris 2.4 (SVR4)
This section contains a list of the SUID and SGID files found in Solaris 2.4, which is representative of System V Release 4
systems in general. Rather than simply presenting a complete list of files, we have annotated the reason that SUID or SGID

permissions are set. Our goal is to teach you how to recognize the SUID/SGID files on your system, and make your own
decision as to whether the privilege is justified, or whether some lesser privilege would suffice.
You can generate your own list of SUID files by using the command:
# find / -type f -perm -04000 -ls
You can generate a list of SGID files by using the command:
# find / -type f -perm -02000 -ls
B.3.1.1 SUID files
-r-sr-xr-x 1 root sys 610480 Aug 3 1994 /sbin/su
-r-sr-xr-x 1 root bin 559968 Aug 3 1994 /sbin/sulogin
-r-sr-xr-x 1 root sys 15156 Jul 16 1994 /usr/bin/su
The su command is SUID root so it can alter the process's effective UID. We don't understand why sulogin needs to be SUID
root, because it is only run when the system boots in single-user mode (and, presumably, it is already running as root). The
/sbin/su program is statically linked, which is why it is so much larger than /usr/bin/su, which uses shared libraries.
-rwsr-xr-x 1 root sys 32144 Jul 15 1994 /usr/bin/at
-rwsr-xr-x 1 root sys 12128 Jul 15 1994 /usr/bin/atq
-rwsr-xr-x 1 root sys 10712 Jul 15 1994 /usr/bin/atrm
The at commands are SUID root because they run commands for all user IDs, and need root permissions to set the user and
[Appendix B] B.3 SUID and SGID Files
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (1 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
group permissions of jobs. Additionally, the directory where these jobs are stored is protected to prevent snooping and
tampering with the files, and root permissions are used to enforce these protections.
-r-sr-xr-x 1 root sys 29976 Jul 16 1994 /usr/bin/chkey
The chkey command is SUID root because it accesses the /etc/publickey database.
-r-sr-xr-x 1 root bin 14600 Jul 15 1994 /usr/bin/cron
The cron program is SUID root so that it can alter files in the /var/spool/cron directory. As with the at commands above, it
also runs jobs under different user IDs and needs root privileges to do so.
-r-sr-xr-x 1 root bin 9880 Jul 16 1994 /usr/bin/eject
-r-sr-xr-x 1 root bin 22872 Jul 16 1994 /usr/bin/fdformat
-r-sr-xr-x 1 root bin 4872 Jul 16 1994 /usr/bin/volcheck

These programs are SUID root because they directly manipulate the floppy disk device.
-r-sr-xr-x 1 root bin 27260 Jul 16 1994 /usr/bin/login
login must be SUID root so that one user can use login to log in as another user without first logging out. If login were not
SUID root, it could not change its real and effective UID to be that of another user. If the program is not SUID, then users
need to log out before logging in as another user - a minor inconvenience. Many site administrators prefer this behavior and
remove the SUID permission on login as a result.
-rwsr-xr-x 1 root sys 9520 Jul 16 1994 /usr/bin/newgrp
newgrp is SUID root because it must alter the process's effective and real group IDs (GIDS).
-r-sr-sr-x 1 root sys 11680 Jul 16 1994 /usr/bin/passwd
This program must be SUID root because it modifies the /etc/passwd or /etc/shadow files.
-r-sr-xr-x 1 root sys 17800 Jul 16 1994 /usr/bin/ps
-r-sr-xr-x 1 root bin 12080 Jul 16 1994 /usr/sbin/whodo
These programs are SUID root because they need access to the computer's /dev/mem and /dev/kmem devices, and to access
some accounting files. Perhaps a safer approach would be to have a kmem group and have needed files be SGID kmem.
-r-sr-xr-x 1 root bin 15608 Jul 15 1994 /usr/bin/rcp
-r-sr-xr-x 1 root bin 60268 Jul 15 1994 /usr/bin/rdist
-r-sr-xr-x 1 root bin 14536 Jul 15 1994 /usr/bin/rlogin
-r-sr-xr-x 1 root bin 7920 Jul 15 1994 /usr/bin/rsh
-rwsr-xr-x 1 root other 7728 Jul 16 1994 /usr/bin/yppasswd
-r-sr-x x 1 root bin 134832 Jul 16 1994 /usr/lib/sendmail
-r-sr-x x 1 root bin 137552 Jul 16 1994 /usr/lib/sendmail.mx
-r-sr-xr-x 1 root bin 17968 Jul 15 1994 /usr/sbin/ping
-r-sr-xr-x 1 root bin 510532 Jul 15 1994 /usr/sbin/static/rcp
In general, these programs are all SUID root because they need to create TCP/IP connections on ports below 1024. The
sendmail program also needs the ability to modify files stored in its working directories. The ping program needs to use raw
IP.
-rws x x 1 uucp bin 55608 Jul 16 1994 /usr/bin/tip
s x x 1 root uucp 68816 Jul 15 1994 /usr/bin/ct
s x x 1 uucp uucp 81904 Jul 15 1994 /usr/bin/cu
These programs are SUID uucp so that they can access the dialer and modem devices.

-r-sr-xr-x 2 root bin 10888 Jul 16 1994 /usr/bin/uptime
-r-sr-xr-x 2 root bin 10888 Jul 16 1994 /usr/bin/w
We can't figure out why these programs are SUID root, as they access files (/var/adm/utmp and /dev/kstat) that are
world-readable. These are hard links which you can verify by using ls -li.
s x x 1 uucp uucp 64240 Jul 15 1994 /usr/bin/uucp
[Appendix B] B.3 SUID and SGID Files
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (2 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
s x x 1 uucp uucp 21304 Jul 15 1994 /usr/bin/uuglist
s x x 1 uucp uucp 17144 Jul 15 1994 /usr/bin/uuname
s x x 1 uucp uucp 60952 Jul 15 1994 /usr/bin/uustat
s x x 1 uucp uucp 68040 Jul 15 1994 /usr/bin/uux
s x x 1 uucp uucp 4816 Jul 15 1994 /usr/lib/uucp/remote.unknown
s x x 1 uucp uucp 169096 Jul 15 1994 /usr/lib/uucp/uucico
s x x 1 uucp uucp 32016 Jul 15 1994 /usr/lib/uucp/uusched
s x x 1 uucp uucp 81040 Jul 15 1994 /usr/lib/uucp/uuxqt
These programs are SUID uucp because they need to access privileged UUCP directories and files.
-r-sr-xr-x 1 root bin 21496 Jul 16 1994 /usr/lib/exrecover
This file is SUID root so that it can access the directory in which editor recovery files are saved. As we have said in other
places in the book, a more secure approach would be to have an account specifically created for accessing this directory, or to
create user-owned subdirectories in a common save directory.
-r-sr-sr-x 1 root tty 151352 Jul 15 1994 /usr/lib/fs/ufs/ufsdump
-r-sr-xr-x 1 root bin 605348 Jul 15 1994 /usr/lib/fs/ufs/ufsrestore
These files are SUID root so that users other than the superuser can make backups. In the Solaris version of these commands,
any user who is in the sys group can dump the contents of the system's disks and restore them without having root access. (As
a result, having sys access on this operating system means that you can effectively read any file on the computer by using a
combination of ufsdump and ufsrestore.) Note: the fact that users in the sys group can dump and undump tapes is not
documented in the man page. Other programs may give undocumented privileges to users who happen to be in particular
groups.
-rwsr-xr-x 1 root adm 4008 Jul 15 1994 /usr/lib/acct/accton

There must be some reason that this program is SUID root. But, once again, we can't figure it out, as the program gives the
error "permission denied" when it is run by anybody other than the superuser.
-rwsr-xr-x 3 root bin 13944 Jul 16 1994 /usr/sbin/allocate
-rwsr-xr-x 3 root bin 13944 Jul 16 1994 /usr/sbin/deallocate
-rwsr-xr-x 3 root bin 13944 Jul 16 1994 /usr/sbin/list_devices
The allocate command allocates devices to users based on the Solaris allocation mechanism. For more information, refer to
the Solaris documentation. We believe that the mkdevalloc and mkdevmaps commands are part of the same system, but they
are not documented.
-rwsr-xr-x 1 root sys 21600 Jul 16 1994 /usr/sbin/sacadm
The sacadm is the top-level entry point into the Service Access Facility system.
-rwsrwxr-x 1 root bin 87808 Jun 24 1994 /usr/openwin/bin/xlock
We think that xlock needs to be SUID root so that it can read your password from the shadow file.
-r-sr-sr-x 1 root sys 20968 Jun 27 1995 /usr/dt/bin/dtaction
-r-sr-xr-x 1 root bin 69172 Jun 27 1995 /usr/dt/bin/dtappgather
-r-sr-xr-x 1 root bin 134600 Jun 27 1995 /usr/dt/bin/dtsession
-r-sr-xr-x 1 root bin 373332 Jun 27 1995 /usr/dt/bin/dtprintinfo
-r-sr-sr-x 1 root daemon 278060 Jun 27 1995 /usr/dt/bin/sdtcm_convert
These programs all appear to perform session management as part of the Common Desktop Environment 1.0. We don't know
why dtaction needs to be SUID root.
B.3.1.2 Undocumented SUID programs
The following programs are SUID and undocumented. This combination is dangerous, because there is no way to tell for sure
what these programs are supposed to do, if they have their SUID/SGID bits properly set, or if they are even part of the
standard operating system release.
s x x 1 root bin 3116 Jul 16 1994 /usr/lib/pt_chmod
[Appendix B] B.3 SUID and SGID Files
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (3 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
-r-sr-xr-x 1 root bin 5848 Jul 16 1994 /usr/lib/utmp_update
-rwsr-xr-x 1 root bin 8668 Jul 16 1994 /usr/sbin/mkdevalloc
-rwsr-xr-x 1 root bin 9188 Jul 16 1994 /usr/sbin/mkdevmaps

-r-sr-sr-x 1 root bin 14592 Jul 15 1994 /usr/openwin/bin/ff.core
-rwsr-xr-x 1 root bin 19580 Jun 24 1994 /usr/openwin/lib/mkcookie
-rwsr-sr-x 1 bin bin 8288 Jul 16 1994 /usr/vmsys/bin/chkperm
-r-sr-xr-x 1 lp lp 203 Jul 18 1994 /etc/lp/alerts/printer
B.3.1.3 SGID files
-rwxr-sr-x 1 root sys 147832 Jul 15 1994 /usr/kvm/crash
-r-xr-sr-x 1 bin sys 31440 Jul 15 1994 /usr/bin/netstat
-r-xr-sr-x 1 bin sys 11856 Jul 16 1994 /usr/bin/nfsstat
-r-xr-sr-x 1 bin sys 11224 Jul 16 1994 /usr/bin/ipcs
-r-xr-sr-x 1 root bin 6912 Jul 15 1994 /usr/sbin/arp
-r-xr-sr-x 1 bin sys 6280 Jul 16 1994 /usr/sbin/fusage
-r-xr-sr-x 1 root sys 15128 Jul 16 1994 /usr/sbin/prtconf
-r-xr-sr-x 1 bin sys 7192 Jul 16 1994 /usr/sbin/swap
-r-xr-sr-x 1 root sys 21416 Jul 16 1994 /usr/sbin/sysdef
-r-xr-sr-x 1 bin sys 5520 Jul 15 1994 /usr/sbin/dmesg
-rwxr-sr-x 1 root sys 12552 Jul 18 1994 /usr/openwin/bin/wsinfo
-rwxrwsr-x 1 root sys 9272 Jul 18 1994 /usr/openwin/bin/xload
These programs examine and/or modify memory of the running system and use group permissions to read the necessary
device files.
-r-xr-sr-x 1 bin sys 28696 Jul 16 1994 /usr/kvm/eeprom
The eeprom program allows you to view or modify the contents of the system's EEPROM. It should probably not be
executable by non-root users.
-r-x s x 1 bin mail 65408 Jul 16 1994 /usr/bin/mail
-r-x s x 1 bin mail 132888 Jul 16 1994 /usr/bin/mailx
-r-xr-sr-x 1 root mail 449960 Jul 15 1994 /usr/openwin/bin/mailtool
-r-xr-sr-x 1 bin mail 825220 Jun 27 1995 /usr/dt/bin/dtmail
-r-xr-sr-x 1 bin mail 262708 Jun 27 1995 /usr/dt/bin/dtmailpr
The mail programs can be used to send mail or read mail in the /var/mail directory. We are not certain why these programs
need to be SGID mail,; however, we suspect it involves lock management.
-r-sr-sr-x 1 root sys 20968 Jun 27 1995 /usr/dt/bin/dtaction

This is another part of the Common Desktop Environment system. We don't know why it is both SUID and SGID.
-r-sr-sr-x 1 root sys 11680 Jul 16 1994 /usr/bin/passwd
We do not know why this program needs to be both SUID root and SGID sys.
-r-xr-sr-x 1 bin tty 9984 Jul 16 1994 /usr/bin/write
-r-sr-sr-x 1 root tty 151352 Jul 15 1994 /usr/lib/fs/ufs/ufsdump
-r-xr-sr-x 1 bin tty 9296 Jul 16 1994 /usr/sbin/wall
These programs are SGID tty so that they can write on the devices of users.
-rwxr-sr-x 1 root root 650620 Jun 24 1994 /usr/openwin/bin/Xsun
Xsun is the X-Window server for the Sun. It is SGID so that it can access necessary device files.
-r-sr-sr-x 1 root daemon 278060 Jun 27 1995 /usr/dt/bin/sdtcm_convert
This program converts files from the Open Windows calendar data format version 3 to version 4. According to the
documentation, sdtcm_convert must be run by the superuser or the owner of the calendar. Users can only run the program on
their own calendars; the superuser can run the program on any calendar. Because the /var/spool/calendar directory is mode
[Appendix B] B.3 SUID and SGID Files
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (4 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
3777, there should be no reason for this program to be SUID or SGID.
B.3.1.4 Undocumented SGID files
These files are not documented in the Solaris system documentation:
-r-sr-sr-x 1 root bin 14592 Jul 15 1994 /usr/openwin/bin/ff.core
-rwsr-sr-x 1 bin bin 8288 Jul 16 1994 /usr/vmsys/bin/chkperm
B.3.2 SUID/SGID Files in Berkeley UNIX
This list of SUID and SGID files in Berkeley UNIX was derived by looking at computers made by Sun Microsystems, Digital
Equipment Corporation, and NeXT Inc. The list of SUID and SGID files on your version of Berkeley UNIX is likely to be
different. For this reason, we not only list which files are SUID and SGID, we also explain why they are SUID or SGID. After
reading this list, you should be able to look at all of the SUID and SGID files on your system and figure out why your files
have been set in particular ways. If you have a question about a file that is SUID or SGID, consult your documentation or
contact your vendor.
B.3.2.1 SUID files
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /usr/etc/ping

ping must be SUID root so that it can transmit ICMP ECHO requests on the raw IP port.
-r-s x x 1 root wheel 16384 Aug 18 1989 /usr/etc/timedc
The timedc (Time Daemon Control) program must be SUID root so that it can access the privileged time port.
-r-sr-x x 3 root wheel 81920 Sep 7 1989 /usr/lib/sendmail
-r-sr-x x 3 root wheel 81920 Sep 7 1989 /usr/bin/newaliases
-r-sr-x x 3 root wheel 81920 Sep 7 1989 /usr/bin/mailq
These programs are all hard links to the same binary. The sendmail program must be SUID root because it listens on TCP/IP
port 25, which is privileged.
-rwsr-xr-x 1 root wheel 16384 Aug 15 1989 /usr/lib/ex3.7recover
-rwsr-xr-x 1 root wheel 16384 Aug 15 1989 /usr/lib/ex3.7preserve
These programs, part of the vi editor system, must be SUID root so they can read and write the backup files used by vi.
(These are often SGID preserve.)
-rws x x 1 root wheel 40960 Nov 15 1989 /usr/lib/lpd
-rws s x 1 root daemon 24576 Sep 6 1989 /usr/ucb/lpr
-rws s x 1 root daemon 24576 Sep 6 1989 /usr/ucb/lpq
-rws s x 1 root daemon 24576 Sep 6 1989 /usr/ucb/lprm
The line-printer daemon must be SUID root so it can listen on TCP/IP port 515, the printer port, and so can read and write
files in the /usr/spool/lpd directory. Likewise, the line-printer user commands must be SUID so they can access spool files
and the printer device.
-rwsr-xr-x 1 root wheel 24576 Aug 18 1989 /bin/ps
-rwsr-xr-x 2 root wheel 57344 Aug 18 1989 /usr/ucb/w
-rwsr-xr-x 2 root wheel 57344 Aug 18 1989 /usr/ucb/uptime
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /usr/bin/iostat
These programs must be SUID root because they need to read the kernel's memory to generate the statistics that they print.
On some systems, these programs are distributed SGID kmem, and /dev/kmem is made readable only by this group. This
second approach is more secure than the first approach.
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /usr/ucb/quota
The quota command must be SUID root so that it can read the quota file.
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /usr/ucb/rcp
[Appendix B] B.3 SUID and SGID Files

file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (5 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
-rwsr-x x 1 root wheel 32768 Aug 18 1989 /usr/ucb/rdist
-rwsr-xr-x 1 root wheel 16384 Aug 23 1989 /usr/ucb/rlogin
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /usr/ucb/rsh
-rwsr-sr-x 1 root tty 32768 Nov 11 17:17 /usr/etc/rdump
These programs must be SUID root because they use privileged ports to do username authentication.
-rwsr-xr-x 1 daemon wheel 16384 Aug 18 1989 /usr/bin/atq
-rwsr-xr-x 1 daemon wheel 16384 Aug 18 1989 /usr/bin/at
-rwsr-xr-x 1 daemon wheel 16384 Aug 18 1989 /usr/bin/atrm
These programs must be SUID because they access and modify spool files that are kept in privileged directories.
-rws x x 2 root daemon 205347 Sep 29 10:14 /usr/bin/tip
-rws x x 2 root daemon 205347 Sep 29 10:14 /usr/bin/cu
tip and cu, which are both hard links to the same binary, must be SUID root so that they can have physical access to the
modem device. On some systems, these files may be SUID UUCP.
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /bin/login
login must be SUID root so that one user can use login to log in as another user, without first logging out. If login were not
SUID root, it could not change its real and effective UID to be that of another user.
-rwsr-xr-x 1 root wheel 16384 Aug 21 1989 /bin/mail
mail must be SUID root so that it can append messages to a user's mail file.
-rwsr-xr-x 1 root wheel 16384 Aug 18 1989 /bin/passwd
-rwsr-xr-x 1 root system 28672 Feb 21 1990 /usr/ucb/chsh
-rwsr-xr-x 1 root system 28672 Feb 21 1990 /usr/ucb/chfn
These programs must be SUID root because they modify the /etc/passwd file.
-rwsr-xr-x 1 root wheel 16384 Sep 3 1989 /bin/su
su must be SUID root so it can change its process's effective UID to that of another user.
s s x 1 uucp daemon 24576 Sep 3 1989 /usr/bin/uucp
s s x 1 uucp daemon 24576 Sep 3 1989 /usr/bin/uux
s s x 1 uucp daemon 16384 Sep 3 1989 /usr/bin/uulog
s s x 1 uucp daemon 16384 Sep 3 1989 /usr/bin/uuname

s s x 1 uucp daemon 16384 Sep 3 1989 /usr/bin/uusnap
s s x 1 uucp daemon 24576 Sep 3 1989 /usr/bin/uupoll
s s x 1 uucp daemon 16384 Sep 3 1989 /usr/bin/uuq
s s x 2 uucp daemon 16384 Sep 3 1989 /usr/bin/uusend
s s x 2 uucp daemon 16384 Sep 3 1989 /usr/bin/ruusend
s s x 1 uucp daemon 90112 Sep 3 1989 /usr/lib/uucp/uucico
s s x 1 uucp daemon 24576 Sep 3 1989 /usr/lib/uucp/uuclean
s s 1 uucp daemon 32768 Sep 3 1989 /usr/lib/uucp/uuxqt
s x x 1 uucp daemon 32768 Feb 21 1990 /usr/var/uucp/uumonitor
s x x 1 uucp daemon 86016 Feb 21 1990 /usr/var/uucp/uucompact
s x x 1 uucp daemon 77824 Feb 21 1990 /usr/var/uucp/uumkspool
s 1 uucp daemon 90112 Feb 21 1990 /usr/var/uucp/uurespool
These UUCP files are SUID uucp so they can access and modify the protected UUCP directories. Not all of these will be
SUID in every system.
-rwsr-xr-x 1 root system 954120 Jun 8 03:58 /usr/bin/X11/xterm
-rwsr-xr-x 1 root system 155648 Nov 16 1989 /usr/lib/X11/getcons
xterm is SUID because it needs to be able to change the ownership of the pty that it creates for the X terminal. getcons is
SUID because it needs to be able to execute a privileged kernel call.
[Appendix B] B.3 SUID and SGID Files
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (6 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
B.3.2.2 SGID files
-rwxr-sr-x 1 root kmem 4772 Nov 11 17:07 /usr/etc/arp
-rwxr-sr-x 1 root kmem 2456 Nov 11 17:14 /usr/etc/dmesg
-rwxr-sr-x 1 root kmem 4276 Nov 11 17:35 /usr/etc/kgmon
-rwxr-sr-x 1 root kmem 5188 Nov 11 18:16 /usr/etc/vmmprint
-rwxr-sr-x 1 root kmem 3584 Nov 11 18:16 /usr/etc/vmoprint
-rwxr-sr-x 1 root kmem 5520 Nov 11 20:38 /usr/etc/nfsstat
-r-xr-sr-x 1 root kmem 32768 Oct 22 10:30 /usr/ucb/gprof
-rwxr-sr-x 1 root kmem 40960 Nov 11 18:39 /usr/ucb/netstat

-rwxr-sr-x 1 root kmem 24576 Nov 11 18:57 /usr/ucb/sysline
-rwxr-sr-x 1 root kmem 76660 Jun 8 03:56 /usr/bin/X11/xload
These commands are SGID because they need to be able to access the kernel's memory.
-rwxr-sr-x 1 root tty 2756 Nov 11 17:05 /bin/wall
-rwxr-sr-x 1 root tty 4272 Nov 11 17:06 /bin/write
These commands are SGID because they need to be able to access the raw terminal devices.
s s x 1 uucp daemon 90112 Nov 11 20:25 /usr/lib/uucp/uucico
s s x 1 uucp daemon 11136 Nov 11 20:25 /usr/lib/uucp/uuclean
s s 1 uucp daemon 32768 Nov 11 20:26 /usr/lib/uucp/uuxqt
s s x 1 uucp daemon 24576 Nov 11 20:25 /usr/bin/uucp
s s x 1 uucp daemon 24576 Nov 11 20:25 /usr/bin/uux
s s x 1 uucp daemon 4620 Nov 11 20:25 /usr/bin/uulog
s s x 1 uucp daemon 5776 Nov 11 20:25 /usr/bin/uuname
s s x 1 uucp daemon 4260 Nov 11 20:26 /usr/bin/uusnap
s s x 1 uucp daemon 24576 Nov 11 20:26 /usr/bin/uupoll
s s x 1 uucp daemon 8716 Nov 11 20:26 /usr/bin/uuq
s s x 2 uucp daemon 3548 Nov 11 20:26 /usr/bin/uusend
s s x 2 uucp daemon 3548 Nov 11 20:26 /usr/bin/ruusend
These commands are all SGID because they need to be able to access UUCP spool files.
-rwx s x 1 root daemon 24576 Oct 27 18:39 /usr/etc/lpc
-rws s x 1 root daemon 40960 Oct 27 18:39 /usr/lib/lpd
-rws s x 1 root daemon 24576 Oct 27 18:39 /usr/ucb/lpr
-rws s x 1 root daemon 24576 Oct 27 18:39 /usr/ucb/lpq
-rws s x 1 root daemon 24576 Oct 27 18:39 /usr/ucb/lprm
These commands are all SGID because they need to be able to access the line-printer device and spool files.
-rwxr-sr-x 1 root operator 6700 Nov 11 16:53 /bin/df
This command is SGID because it needs access to the raw disk device (which is owned by the group operator on some
versions of Berkeley UNIX).
B.2 Important Files in Your
Home Directory

C. UNIX Processes
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Appendix B] B.3 SUID and SGID Files
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/appb_03.htm (7 of 7) [2002-04-12 10:45:19]
Simpo PDF Merge and Split Unregistered Version -
Chapter 1

1. Introduction
Contents:
What Is Computer Security?
What Is an Operating System?
History of UNIX
Security and UNIX
Role of This Book
In today's world of international networks and electronic commerce, every computer system is a potential
target. Rarely does a month go by without news of some major network or organization having its
computers penetrated by unknown computer criminals. Although some computer "hackers" (see the
sidebar below) have said that such intrusions are merely teenage pranks or fun and games, these
intrusions have become more sinister in recent years: computers have been rendered inoperable; records
have been surreptitiously altered; software has been replaced with secret "back doors" in place;
proprietary information has been copied without authorization; and millions of passwords have been
captured from unsuspecting users.
Even if nothing is removed or altered, system administrators must often spend hours or days reloading
and reconfiguring a compromised system to regain some level of confidence in the system's integrity.
There is no way to know the motives of an intruder and the worst must be assumed. People who break
into systems simply to "look around" do real damage, even if they do not read confidential mail and do
not delete any files. If computer security was once the subject of fun and games, those days have long
since passed.
Many different kinds of people break into computer systems. Some people - perhaps the most widely
publicized - are the equivalent of reckless teenagers out on electronic joy rides. Like youths who

"borrow" fast cars, their main goal isn't necessarily to do damage, but to have what they consider to be a
good time. Others are far more dangerous: some people who compromise system security are sociopaths,
joyriding around the networks bent on inflicting damage on unsuspecting computer systems. Others see
themselves at "war" with rival hackers; woe to innocent users and systems who happen to get in the way
of cyberspace "drive-by shootings!" Still others are out for valuable corporate information, which they
hope to resell for profit. There are also elements of organized crime, spies and saboteurs motivated by
both greed and politics, terrorists, and single-minded anarchists using computers and networks.
Who Is a Computer Hacker?
[Chapter 1] Introduction
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_01.htm (1 of 4) [2002-04-12 10:45:20]
Simpo PDF Merge and Split Unregistered Version -
HACKER noun 1. A person who enjoys learning the details of computer systems and how
to stretch their capabilities - as opposed to most users of computers, who prefer to learn only
the minimum amount necessary. 2. One who programs enthusiastically or who enjoys
programming rather than just theorizing about programming.
Guy L. Steele, et al., The Hacker's Dictionary
There was a time when computer security professionals argued over the term "hacker." Some thought
that hackers were excellent and somewhat compulsive computer programmers, like Richard Stallman,
founder of the Free Software Foundation. Others thought that hackers were computer criminals, more
like convicted felon Mark Abene, a.k.a "Phiber Optik." Complicating this discussion was the fact that
many computer security professionals had formerly been hackers themselves - of both persuasions. Some
were anxious to get rid of the word, while others wished to preserve it.
Today the confusion over the term hacker has largely been resolved. While some computer professionals
continue to call themselves "hackers," most don't. In the mind of the public, the word "hacker" has been
firmly defined as a person exceptionally talented with computers who often misuses that skill. Use of the
term by members of the news media, law enforcement, and the entertainment industry has only served to
reinforce this definition.
In some cases, we'll refer to people who break into computers, and present a challenge for computer
security, by a variety of names: "crackers," "bad guys," and occasionally "hackers." However, in general,
we will try to avoid these labels and use more descriptive terms: "intruders," "vandals," or simply,

"criminals."
The most dangerous computer criminals are usually insiders (or former insiders), because they know
many of the codes and security measures that are already in place. Consider the case of a former
employee who is out for revenge. The employee probably knows which computers to attack, which files
will cripple the company the most if deleted, what the defenses are, and where the backup tapes are
stored.
Despite the risks, interest in computer networking and the Internet has never been greater. The number of
computers attached to the Internet has approximately doubled every year for nearly a decade. By all
indications, this growth is likely to continue for several years to come. With this increased interest in the
Internet, there has been growing interest in UNIX as the operating system of choice for Internet
gateways, high-end research machines, and advanced instructional platforms.
Years ago, UNIX was generally regarded as an operating system that was difficult to secure. This
reputation was partially unfounded. Although part of UNIX's poor reputation came from design flaws
and bugs, a bigger cause for blame rested with the traditional use of UNIX and with the poor security
consciousness of its users. For its first 15 years, UNIX was used primarily in academia, the computing
research community, the telephone company, and the computer industry itself. In most of these
environments, computer security was not a priority (until perhaps recently). Users in these environments
often configured their systems with lax controls, and even developed philosophies that viewed strong
security as something to avoid. Because they cater to this community (and hire from it), many UNIX
vendors have developed a culture that has been slow to incorporate more practical security mechanisms
into their products.[1]
[Chapter 1] Introduction
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_01.htm (2 of 4) [2002-04-12 10:45:20]
Simpo PDF Merge and Split Unregistered Version -
[1] James Ellis at CERT suggests that another reason for UNIX's poor security record has to
do with the wide-spread availability of UNIX source code, which allows for detailed
inspection by potential attackers for weaknesses. Buffer overflows or coding errors that
would be reported on other systems as merely causing crashes are reported frequently on
UNIX with detailed programs that break system security.
Perhaps the best known demonstration of UNIX vulnerability to date occurred in November 1988. That

was when Robert T. Morris released his infamous "Internet worm" program, which spread to thousands
of computers in a matter of hours. That event served as a major wake-up call for many UNIX users and
vendors. Since then, users, academics, and computer manufacturers have usually worked together to try
to improve the security of the UNIX operating system. Many of the results of those efforts are described
in this book.
But despite the increasing awareness and the improvements in defenses, the typical UNIX system is still
exposed to many dangers. The purpose of this book is to give readers a fundamental understanding of the
principles of computer security and to show how they apply to the UNIX operating system. We hope to
show you practical techniques and tools for making your system as secure as possible, especially if it is
running some version of UNIX. Whether you are a user or administrator, we hope that you will find
value in these pages.
1.1 What Is Computer Security?
Terms like security, protection, and privacy often have more than one meaning. Even professionals who
work in information security do not agree on exactly what these terms mean. The focus of this book is
not formal definitions and theoretical models so much as practical, useful information. Therefore, we'll
use an operational definition of security and go from there.
Computer Security: "A computer is secure if you can depend on it and its software to behave as you
expect."
If you expect the data entered into your machine today to be there in a few weeks, and to remain unread
by anyone who is not supposed to read it, then the machine is secure. This concept is often called trust:
you trust the system to preserve and protect your data.
By this definition, natural disasters and buggy software are as much threats to security as unauthorized
users. This belief is obviously true from a practical standpoint. Whether your data is erased by a vengeful
employee, a random virus, an unexpected bug, or a lightning strike - the data is still gone.
Our practical definition might also imply to some that security is concerned with issues of testing your
software and hardware, and with preventing user mistakes. However, we don't intend our definition to be
that inclusive. That's why the word "practical" is in the title of this book - and why we won't try to be
more specific about defining what "security" is, exactly. A formal definition wouldn't necessarily help
you any more than our working definition, and would require detailed explanations of risk assessment,
asset valuation, policy formation, and a number of other topics beyond what we are able to present here.

On the other hand, knowing something about these concepts is important in the long run. If you don't
know what you're protecting, why you're protecting it, and what you are protecting it from, your task will
be rather difficult! Furthermore, you need to understand how to establish and apply uniform security
[Chapter 1] Introduction
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_01.htm (3 of 4) [2002-04-12 10:45:20]
Simpo PDF Merge and Split Unregistered Version -
policies. Much of that is beyond the scope of what we hope to present here; thus, we'll discuss a few of
these topics in Chapter 2, Policies and Guidelines, Policies and Guidelines. We'll also recommend that
you examine some of the references available. Several good introductory texts in this area, including
Computer Security Basics (Russell and Gangemi), Computer Crime: A Crimefighter's Handbook (Seger,
VonStorch, and Icove), and Control and Security of Computer Information Systems (Fites, Kratz, and
Brebner) are listed in Appendix D, Paper Sources. Other texts, university courses, and professional
organizations can provide you with more background. Security isn't a set of tricks, but an ongoing area of
specialization.
This book emphasizes techniques to help keep your system safe from other people - including both
insiders and outsiders, those bent on destruction, and those who are simply ignorant or untrained. The
text does not detail every specific security-related feature that is available only on certain versions of
UNIX from specific manufacturers: companies that take the time to develop such software usually
deliver it with sufficient documentation.
Throughout this book, we will be presenting mechanisms and methods of using them. To decide which
mechanisms are right for you, take a look at Chapter 2. Remember, each site must develop its own
overall security policies, and those policies will determine which mechanisms are appropriate to use. End
users should also read Chapter 2 - users should be aware of policy considerations, too.
For example, if your local policy is that all users can build and install programs that can be accessed by
other users, then you may wish to set the file permissions on /usr/local/bin to be mode 1777, which
allows users to add their own files but does not generally allow them to delete files placed there by other
users. If you don't wish to take the risk of allowing users to install publicly accessible programs that
might contain Trojan horses or trap doors,[2] a more appropriate file permissions setting for
/usr/local/bin might be 755.[3]
[2] For an example of such a program, consider a rogue user who installs a program called ls

that occasionally deletes files instead of listing them.
[3] See Chapter 5, The UNIX Filesystem, for a discussion of these protection modes.
I. Computer Security Basics 1.2 What Is an Operating
System?
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
[Chapter 1] Introduction
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch01_01.htm (4 of 4) [2002-04-12 10:45:20]
Simpo PDF Merge and Split Unregistered Version -