248 Security
Now, what’s wrong with this? Ping, it turns out, is a setuid root pro-
gram, and now when I’m done with it I CAN’T KILL THE PRO-
CESS BECAUSE UNIX SAYS IT’S NOT MINE TO KILL! So I
think “No prob, I’ll log out and then log back in again and it'll catch
SIGHUP and die, right?” Wrong. It’s still there and NOW I'M
TRULY SCREWED BECAUSE I CAN'T EVEN TRY TO FG IT!
So I have to run off and find someone with root privileges to kill it
for me! Why can’t Unix figure out that if the ppid of a process is the
pid of your shell, then it’s yours and you can do whatever you bloody
well please with it?Unix security tip of the day:You can greatly reduce your chances of breakin by crackers and
infestation by viruses by logging in as root and typing:% rm /vmunixProcesses Are Cheap—and Dangerous
Another software tool for breaking Unix security are the systems calls
fork() and exec(), which enable one program to spawn other programs.
Programs spawning subprograms lie at the heart of Unix’s tool-based phi-
losophy. Emacs and FTP run subprocesses to accomplish specific tasks
such as listing files. The problem for the security-conscious is that these
programs inherit the privileges of the programs that spawn them.Easily spawned subprocesses are a two-edged sword because a spawned
subprogram can be a shell that lowers the drawbridge to let the Mongol
hordes in. When the spawning program is running as superuser, then its
spawned process also runs as superuser. Many a cracker has gained entry
through spawned superuser shells.Indeed, the “Internet Worm” (discussed later in this chapter) broke into
unsuspecting computers by running network servers and then convincing
them to spawn subshells. Why did these network servers have the appropri-
ate operating system permission to spawn subshells, when they never have
to spawn a subshell in their normal course of operation? Because every
Unix program has this ability; there is no way to deny subshell-spawning
privileges to a program (or a user, for that matter).