From kragen@dnaco.net Tue Jul 7 19:37:01 1998 Date: Tue, 7 Jul 1998 19:37:00 -0400 (EDT) From: Kragen To: Alan Cox cc: Kragen , 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: Message-ID: 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