Re: chroot useful? (fwd)

Alexander Kjeldaas (astor@guardian.no)
Sun, 9 Nov 1997 15:55:10 +0100 (MET)


On Sun, 9 Nov 1997, Darren Reed wrote:

> In some mail I received from Claudio Telmon, sie wrote
> > From owner-firewall-wizards@nfr.net Sun Nov 9 12:44:11 1997
> > Message-ID: <3464BFA2.58CB45C1@link.it>
> > Date: Sat, 08 Nov 1997 20:38:10 +0100
> > From: Claudio Telmon <claudio@link.it>
> > X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i586)
> > MIME-Version: 1.0
> > To: firewall-wizards@nfr.net
> > Subject: chroot useful?
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> > Sender: owner-firewall-wizards@nfr.net
> > Precedence: bulk
> > Reply-To: Claudio Telmon <claudio@link.it>
> >
> > 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?
> > 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?
> > And finally: if the above is correct, what's the usefulness of chroot,
> > besides giving some more trouble to the hacker?

Mounting /proc in a chrooted environment also has advantages. When
we create a new version of our linux distribution it's done in a
chrooted environment. Since some configure-script need access to
/proc, being able to mount it in a chrooted environment is an
advantage. Chroot in itself is _not_ a security mechanism.

For better security, look at the capabilities patch for 2.1 available at
ftp://ftp.guardian.no/pub/free/linux/capabilities/. Using this patch, it's
easy to disable certain privileges in the chrooted environment, such as
the ability to mount. Another advantage is that you don't need to run
under uid 0 anymore so even if you break out of the chrooted environment,
discretionary access control will stop you from doing harm to the rest of
the system.

astor

--
 Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
 http://www.guardian.no/