[lkml]   [1996]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Glitch in sys_chroot()

On Fri, 15 Nov 1996, Alan Cox wrote:
> Changing chroot, and being able to discard all existing directory handles
> is part of being able to build a secure subenvironment for users to play in.

But security is only _one_ issue with "chroot()".

There are actually other uses for chroot(), like just creating a temporary
environment that gives another view of the system. It doesn't have to be
security-oriented per se, it can be used more to just have two independent
environments for working.

In some cases you'd _want_ to be able to move between environments.
Focusing on only security is silly: the whole basic design of UNIX is to
allow the user to do what he wants, not to make it harder to do "strange"

For example, when Linux/alpha got ELF libraries, the first test-
environment was done under chroot. Not due to security at all, but in
order to install a new set of binaries without having to throw the old
(stable) set away. For that kind of chroot() use it would have been
positively detrimental to make chroot() do anything more than it does now.

Just as an example, with the current chroot() behaviour we can do stuff
like this:

- install a new test-gcc in a chroot environment
- compile programs _outside_ the chroot-environment with

change_root /gcc /usr/bin/gcc file.c -o file.o

and magically it all works correctly: the compiler (and all header files:
/usr/include etc) come from the chroot'ed environment, while the "file.c"
and "file.o" files are from _outside_ the chroot() environment exactly
because we do not change the current working directory.

In short, if you look at chroot() as only a security feature, you're
missing a lot of the implications of chroot(). I'm not so stupid that I'd
limit a very useful system call only because there are stupid programs out
there that can't do a "chdir()" at the same time as chroot.

So until somebody comes up with a GOOD argument for doing chdir()
automatically, this discussion is ended. Please think of ALL the
implications, and don't concentrate on just one small part of the system

As I said, security isn't trivial, and anybody who thinks he can get rid
of security holes by trivial fixes is very naive indeed. Sure, you can
make any system secure by disabling useful features, but that's just plain

Just to show exactly HOW stupid this whole discussion is, here's inane
argument #1: "The suid/sgid bits are the main source of security holes, so
why don't we disable those altogether, and then we'll have a secure

I'm not that stupid,


 \ /
  Last update: 2005-03-22 13:37    [W:0.070 / U:3.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site