In some mail I received from Claudio Telmon, sie wrote
>
> 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:
> connect to other ports using the loopback interface, connect to internal
> hosts etc. These days I was talking about this with a list member, so I
> 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.
> It seems to be actually obvious, since the proc filesystem is an
> interface to the kernel, and the kernel is still there even in chroot.
> My questions are:
> 1) Did I miss something so that my test is meaningless?
No.
> 3) Is the problem common on other systems with the proc file system?
Not *BSD anyway. Procfs (and kernfs) can be excluded from the kernel
when you build them. Although they can then be modloaded, if you're
allowing modloads in multiuser mode on your firewall, then you're just
asking for trouble.
> 4) I didn't try mknod, but it should work the same way, right?
Yes. On a typical system, getting root in a chroot'd environment can mean
"game over". When you start doing things like making kmem read-only,
disallowing various system calls (mknod, for example), preventing raw
devices from being opened, then chroot'd environments become safer places
to let root programs run wild.
> And finally: if the above is correct, what's the usefulness of chroot,
> besides giving some more trouble to the hacker?
The whole world isn't Linux, so don't lose heart, just chose a more secure
Operating System :)
Darren
Received on Nov 09 1997
Intro
