As the family system administrator and computer guru, I'm used to getting
called at work when someone at home is having problems. But I was still
unprepared for the latest call. When my wife put my 14-year-old daughter
on the phone, she said. ``I need the root password.''
Now, root is the login name of the system administrator on a
Unix or Linux machine. It's roughly equivalent to asking for the keys to
the family car.
``What do you think you need to do with it?''
``My friend told me about this program: it makes the list
command in IRC work better. You have to be root to install it.''
``So let me get this straight. You want to download some random program off the net and install it on the server. No. Installing stuff off the net can be very dangerous. Why don't you wait until I get home and we can discuss this...'' Just like a typical father, I guess.
As of the time of writing we still haven't had that talk, but we will. There are really four things at issue:
root
root safely
While viruses, worms, and trojan horse programs aren't as common on Linux
as they are on Windows (Linux is both a smaller target, and far better
protected), there are still a lot of malicious people on the Net. Even if
you're not root, a program you install for your own use can
still wipe out your own home directory (including your homework), and
maybe a few other places where you have write permission.
It can do other things, possibly worse. It can mail your password file to a cracker site. It can look around in your home directory for a secret, like your credit card number, and mail that. It can send embarassing e-mail to all the people in your address book -- in your name! Information is different from cash and jewelry -- after it's been stolen, you still have it. How could you tell?
A program doesn't even have to be maliciously written in order to do considerable damage: just badly written. A simple script with a simple error might wipe out all your files, and it wouldn't matter that the author didn't mean to do it. It's bad enough when you do it to yourself...
That said, there are lots of ways to protect yourself.
cvs. Put the
version repository (CVSROOT) on another disk drive from the one your
home directory is on.
metalab.unc.edu are
good, but break-ins aren't unknown.
Once you've installed software, there are more things you can do:
cp valuable-file.foo valuable-file.foo.bak
root One thing Katy doesn't know is that she, like any Linux user, can
install programs for her own use in her home directory. Most users make a
subdirectory called ``bin'' (short for ``binary'' -- it's an
old Unix tradition) in their home directory.
To use a personal bin directory, you have to ``put it in
your PATH''. The program that actually runs commands, called
the ``shell'', has a list of directories called the ``search path'' where
it looks for programs to run. So when you type a command like
``ls'' or click on an icon to run Netscape, the shell looks
for a file named ls or netscape in each of a
half-dozen or so places, which you can list by typing:
<steve 504> echo $PATH
/usr/local/java/bin:/home/steve/bin:/usr/local/bin:/usr/java/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/games
Notice that the directories in the path are separated by colons. To add
the ``bin'' subdirectory of your home directory to
PATH you need to use a text editor to put a line like this
into the file called .bashrc (or, depending on how your
system is set up, possibly .profile or
.bash_profile) in your home directory:
export PATH=$HOME/bin:$PATH
(If you're on a BSD-based system, or your system administrator was trained
on one, you may be using csh or tcsh instead of
bash as your shell. In that case you need to edit
.cshrc instead of .bashrc, and add:
set path = ( $HOME/bin $path )
In order for this to take effect, you will probably have to log out and
log back in again. (You could execute the export command in
an xterm window, but it would only affect that window and not
your window manager, which got its PATH set up when you
logged in.)
Now, when you install a program in your personal bin
directory, it will run when you type its name. Provided, that is, that
it's marked as ``executable''.
Take a close look at a long directory listing (ls -l)
sometime.
ls -l bin total 77 drwxrwxr-x 2 steve users 1024 Jul 10 23:20 CVS drwxrwxr-x 2 steve users 1024 Jul 10 23:22 Old -rwxrwxr-x 1 steve users 91 Sep 9 1994 addgroups -rwxr-xr-x 1 steve users 517 Apr 19 1988 autodoc -rwxr-xr-x 1 steve users 96 Apr 20 1990 banner_clock -rwxrwxr-x 1 steve users 400 Sep 18 1997 blacken -rwxrwxr-x 3 steve users 64 Jul 25 1997 bolero -rwxr-xr-x 1 steve users 40 Jul 19 1990 ccc -rwxr-xr-x 1 steve users 46 Jul 19 1990 ccx -rwxrwxr-x 1 steve users 288 Sep 18 1997 cpltree -rwxrwxr-x 1 steve users 258 Sep 18 1997 cptree
See the ``rwx's'' in the first column? Those stand for read,
write, and execute permission, respectively. The first group of three is
for me, the next for the users group, and the third for
everyone else. In order for a file to be recognized as a command, the
``x'' flag has to be turned on.
Most software that you download in binary (executable) form comes in a
tar archive, and anything that's supposed to be executable
will still have its permissions set correctly after you unpack it.
Similarly, software that you build (compile) and install yourself will be
executable. The problem comes when you download just an
executable program, for example using ftp or a web browser.
In this case, you have to mark the file as executable. Another
way of describing this process is ``changing the file's mode'', and the
command you need is chmod:
chmod +x foo
Not so hard, is it? For more on what chmod can do, look at
the online manual:
man chmod
root safely The root account can do anything, bypassing all
ownership-based file permissions and other tests. Because it's so
powerful, root is also called the superuser. With
all that power at your fingertips, how do you use it wisely?
The main thing is: use it as little as possible. Above all, don't stay
logged in as root (no matter how easy it is to dedicate a
virtual terminal to it). Log in as yourself, su to
root, do what you need to, and exit back to
being yourself.
The sudo command makes this even easier: you can designate a
set of users, and a set of commands (possibly different for each user)
that they can do using their own password.
If you need to work on your home machine remotely over the Internet, get
and install ssh (Secure SHell) from OpenSSH.org. This is a package that
provides a securely encrypted connection between two machines. In
particular, passwords are encrypted, so somebody in between with
a packet sniffer (there are such things) can't steal your password.
ssh also provides a secure proxy for the X11 protocol, so you
can use X applications over the same secure connection.
If you need to do anything complicated, (for example, making a backup
tape, adding a newsgroup, copying a directory tree, etc.) write a script.
Start by preceeding any dangerous commands, like rm, with
echo so you can see what you're going to be doing to
yourself. Add a little note to yourself in the documentation comments.
For example, here's my command to copy a directory tree, staying in one
filesystem:
#!/bin/csh -f # cpltree src dst # $Id: cpltree,v 1.1 1997/09/19 04:27:18 steve Exp $ # # copy a directory tree (on the same machine) # STAY ON ONE FILE SYSTEM if ($#argv != 2) then echo usage: $0 src dst exit endif if (! -e $2) mkdir $2 (cd $1; tar clf - .) | (cd $2; tar xvpBf -)
(You can tell it's from my old Sun days because it uses csh
instead of bash. But it works and I haven't had to look at
it for years and years.)
Anyone who can get to the keyboard and reboot a Linux box can ``get root'' on it by rebooting in ``single user mode''. You can make this more difficult by
Unfortunately, these steps also make it difficult (perhaps impossible) to repair your system when something goes wrong, and even then you're not completely safe. It's always possible for someone to take the hard drive out, put it on another machine as a secondary drive, edit the password file, and put it back. You could weld the case shut, but...
So you may as well accept the fact that your teenager is going to have root on their own machine at some point. Now what?
The best thing you can do, and the most important, is to make sure that everyone in the family understands that it's their server, their network, and their data. Make sure everyone understands how what they do affects the security of everyone else's data. Get them interested in keeping it safe. Make them active stakeholders. Make sure it's the family's machine.
As soon as a kid is ready for it, let them play around with being
root on their own machine. Give them some responsibility.
Make them part of the solution before they become part of the problem.
I'm not sure how you can tell when a kid is ready for this, but certainly when they figure out how to boot single-user you may as well bow to the inevitable and buy them a book on Linux system administration.
Whether the family is solidly behind you or not, it doesn't hurt to be
careful. After all, it's just as easy for an untrained or careless
root user to wipe out your system as it is for a malicious
one. Maybe easier. Heck, it's easy enough even when you think you're
being careful!
Apart from the things you do to make using root safer, there
are things you can do to make your system harder to mess up.
katy has her own machine,
called chaos, set up /etc/exports to make
sure that the only directory exported with read-write access to
chaos is /home/katy. Don't even allow read
access to the rest of /home.
The reason for this is simple: root can change user
ID's to look like anyone else, and can do it without a password. Even
if someone doesn't have root access on a machine, they can
still read and write the files of any ordinary user if they can access
them over NFS (the Network File System). Oops!