> I always had some doubts about the real protection that a chrooted
> environment can give. As you know, there is a lot of things that can be
> done in this environment, supposing you can bring some binaries in it:
...
> tried on a linux box to mount the /proc filesystem in a chrooted
> environment, and it worked. I had immediate access to all the process
> descriptors, filtering rules and all a hacker may dream to reach in a
> system.
...
> 1) Did I miss something so that my test is meaningless?
> 2) I used the chroot command, not the system call; could the problem be
> a consequence of a buggy implementation of the command? Maybe I should
> try using the system call in a C program...
> 3) Is the problem common on other systems with the proc file system?
> 4) I didn't try mknod, but it should work the same way, right?
Why does your 'chroot'ed environment have 'mount' and 'mknod' in the
first place? Minimalize! Give them the very least they need to do
what they need to do.
And DON'T let them bring in their own fun little binaries.
> And finally: if the above is correct, what's the usefulness of chroot,
> besides giving some more trouble to the hacker?
Locks are rated as to their utility under different circumstances: so
many weeks against blind fumbling, so many days against a skilled
attack, so many hours against power tools, so many seconds against
explosives. ;-) They are never guarantees that nobody will get
through them; only an additional layer of deterrent, so that perhaps
somebody will decide that it's not worth while to go through THIS door
... perhaps a window will be open somewhere?
Similarly, chrooting is a deterrent, not a guarantee (and, especially,
not as much of a guarantee as it used to be). Yes, it would be nice if
it compartmented more than it did. In fact, that's an interesting
idea: as chroot partitions the file system, perhaps there might be
other services to partition off other kernel services? For the future.
--
Joe Yao jsdy_at_cospo.osis.gov - Joseph S. D. Yao
COSPO Computer Support EMT-A/B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.
Received on Nov 10 1997
Intro
