From kragen@dnaco.net Tue Jul  7 19:37:01 1998
Date: Tue, 7 Jul 1998 19:37:00 -0400 (EDT)
From: Kragen <kragen@dnaco.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
cc: Kragen <kragen@pobox.com>, jneves@rnl.ist.utl.pt, astor@guardian.no, 
    mitch@execpc.com, fjcfma@rnl.ist.utl.pt, 
    security-audit@ferret.lmh.ox.ac.uk
Subject: Re: chroot issue (was: Dynamic linker issues... )
In-Reply-To: <m0ytfuq-000aQEC@the-village.bc.nu>
Message-ID: <Pine.SUN.3.96.980707191848.6013A-100000@picard.dnaco.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Keywords:
X-UID: 343
Status: O
X-Status: 

On Tue, 7 Jul 1998, Alan Cox wrote:
> > I'd be obliged if someone could list the thousands of ways.  I know of
> > only a few:
> > - network access (socket(), bind(), connect())

(AFAIK, you can't normally use these to get unchrooted root in the rest
of the system, but they do represent communication with the outside
world.)

> > - /proc
> > - kill()
> > - foolish programs with vulnerabilities reading input data from files
> >   inside the jail and becoming Trojan horses for an attacker
> 
> iopl
> ioperm
> mknod/mmap
> ptrace
> sig I/O on handles across the chroot has some effect
> chroot

add to list:

prev_mknod
stty
stime
acct?
phys (did it ever get implemented?)
and probably, as you say, about a hundred others.

Clearly, if one were to implement such a jail, it would have to be a
fail-closed, whatever-is-not-explicitly-allowed-is-forbidden thing.  My
Linux-2.0.30 kernel has 166 syscalls, including obsolete and obscure
ones.

(I know I shouldn't be running 2.0.30.)

The "capabilities" facility (shouldn't it really be called
"privileges"?  It's privileges like VMS, not capabilities like KeyKOS)
is really the right answer -- when you run named, it shouldn't *have*
to be root.  It just needs to bind to a low port.  Even sendmail
doesn't need to call iopl, phys, or ptrace; it just needs to set its
uid to any normal user on the system.

Kragen