At 08:38 AM 11/15/97 -0500, Anton J Aylward wrote:
>
>Could you clarify this please.
>
>Suppose I have a subdirectory which I chroot to which has the
>following subdirectories:
> etc
> contains passwd with single non root entry
> no other files
> bin
> contains statically linked resticted shell
> preferably a very limited one. not bash, csh or bsh
> dev
> contains nothing
> lib
> contains nothing
> home
> contains nothing
>
>I now have a program which, as root, chroot()s to this point
>sets PATH to "/bin", does a change uid and group to 999 and then
>execls the statically linked restricted shell.
>
>So, not being root, not having the utilities, anyone breaking in here
>must have to download their own binaries, I suppose.
There are a lot of possibilites for the attacker. The most obvious is to
exploit the single most common bug we're seeing today: buffer overflows.
That permits execution of other code, if that bug (or others!) exists.
What can that code do? Well, there have been (rare) kernel bugs that allow
a process to overwrite arbitrary areas of memory. (For example, a few years
ago there was a bug in the SPARC divide instruction emulator routine that
had that property.) Given that, I can get root. Or I can overwrite the
chroot() pointer with something else. Or maybe I can't get root, but I
can issue socket() calls and the like
>
>Or is there something else going on. Like trolling for
>Rick Smith and his debates about chroot vs the Type Enforcement
>such as is used in Sidewinder, which occurred in the old Brent Chapman's
>Firewalls group around the begriming of 1997, a debate Marcus was
>also involved in. You're welcome to review his arguments against
>chroot, which were essentially that the chroot "jail" wa a side effect of
>the virtualization of the file system that Dennis developed and - to
>some degree - a misinterpretation and debasement of its function.
>Sort of like using a knife as a screwdriver. Rick advocated
>type enforcement, not because his company produced a product which used
>is, but because it was correct by design for this function.
I'm not suggesting (or condemning) type enforcement (nor do I wish to restart
that debate). Let it suffice to say that DTE has more of the right flavor
than does chroot() for this purpose, but it's far from perfect.
As for the other suggestions that you and others have made for locking down
a UNIX-flavored system: many of these have the right flavor. All of them
involve making complex decisions, such as the resolv.conf dependency
mentioned by Marcus. And you might miss something -- there are lots of
system calls these days, and the interactions are complex. Or there might
be other flaws in the environment passed to the application, such as open
file descriptors.
I like chroot() for file restrictions because both the concept and the
implementation are very simple. Securing an execution environment is far
more complex, and hence far harder to get right. At that, I'll note that
the original public release of chroot() itself was insecure, and that even
today there is still the subtle relationship between working directory and
root.
Received on Nov 17 1997
Intro
