Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!decvax!tektronix!teklds!copper!stevesu
From: stevesu@copper.UUCP
Newsgroups: net.unix-wizards
Subject: Re: chroot(2) security
Message-ID: <655@copper.UUCP>
Date: Thu, 9-Oct-86 01:06:45 EDT
Article-I.D.: copper.655
Posted: Thu Oct  9 01:06:45 1986
Date-Received: Fri, 10-Oct-86 00:13:49 EDT
References: <158@itcatl.UUCP> <113@nonvon.UUCP> <233@BMS-AT.UUCP> <358@maynard.UUCP>
Organization: Tektronix Inc., Beaverton, Or.
Lines: 63
Summary: Never rationalize removing security protections

In article <358@maynard.UUCP>, campbell@maynard.UUCP (Larry Campbell) writes:
> It seems to me that if /mnt23, say, is on
> a filesystem on which no suid programs exist, you're safe.

Disclaimer: I am about to make sweeping generalities.
Nit-pickers sign off now.

"There is no such thing as a small change to a large system."
Unix is a large system; it is virtually impossible to correctly
predict all of the ramifications which might ensue from making a
fundamental change, such as making chroot() world-executable.

This is because, over time, any number of assumptions may have
been made based on the system's behavior at the time (in this
case, the fact that chroot has historically required root
privilege).  Many of the assumptions are implicit; nobody
realized that they were depending on something; things happened
to work, so nobody worried about it.

Let me illustrate with a simple example:  chown() is also only
executable by root.  The man page explains that this is
"because if users were able to give files away, they could defeat
the file-space accounting procedures."  (Actually, it said this
even before there were file-space accounting procedures.)
The implication is that if you don't care about file-space
accounting, it's safe to allow anyone to invoke chown().  WRONG!
The file-space accounting problem may have been the only problem
with giving files away the day chroot() was conceived, but over
the years, other reasons have developed.  For instance, if your
version of Unix lets me give files away (and there are versions
of Unix that do) but additional security precautions haven't been
added to the _a_t command, I can break security in a hurry.

A similar problem exists with respect to a kernel change which
doesn't even appear at first to concern security: symbolic links.
I won't go into the details, because the hole I'm thinking of
exists in many versions of Unix today ("fixed in 4.3").

If someone claims that a proposed major change is safe, don't
believe him.  If he claims that it's safe "with these
restrictions," or "as long as you also do this," believe him even
less -- where there's one exception, there's bound to be another
one (or another ten) that you haven't thought of yet.

Security on Unix is a particularly hard problem because trying to
prove that Unix is secure is like trying to prove that all crows
are black.  To prove that Unix is safe, you have to inspect every
setuid program, every directory directly or indirectly containing
programs ever exec'ed by root, every... (the list goes on and on).
The hacker has it much easier: to prove that Unix isn't secure, he
only has to find one loophole (like finding one purple crow).

Once (you think) you've proved Unix secure, if you make even one
little change anywhere near a security feature, you have to go
through the entire proof again, and there are probably more
setuid programs than there were last time.  What's "anywhere near
a security feature"?  Unfortunately, that's hard to pin down.
Any system call that says it's only executable by root is
obviously suspect, but (as the symbolic link issue points out)
the list doesn't end there.

                                         Steve Summit
                                         tektronix!copper!stevesu