[1528] in linux-security and linux-alert archive
[linux-security] Re: Re: Re: Buffer Overflows: A Summary
daemon@ATHENA.MIT.EDU (Phexro)
Mon May 5 06:45:40 1997
Date: Sun, 4 May 1997 15:21:21 -0700 (PDT)
From: Phexro <ieure@linknet.kitsap.lib.wa.us>
To: linux-security@redhat.com
In-Reply-To: <Pine.LNX.3.95.970503190235.5733A-100000@puck.nether.net>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
On Sat, 3 May 1997, Myles Uyema wrote:
> [mod: deletia]
> > + but the sysadmin has mounted the partition containing the jail
> > with the nodev option
> >
> > - but the attacker can create and mount a loopback filesystem inside
> > the jail allowing devices to be created
>
> Go back to nodev. Mounting a loopback filesystem requires /dev/loop*
> of type Block, major 7, minor 0 through ??.
>
> [mod: Also noted by John Goerzen]
>
> [mod: But from reading the source I think you don't need a /dev entry
> to remount the partition without the nodev. Moreover you could MAKE
> the /dev entry and use that if it were necessary. But that is not the
> issue. The issue is that a chrooted environment is not protected against
> a root-user inside the chrooted environment. Try
> int i, mypid =getpid ();
> for (i=2;i<32768;i++)
> if (i != mypid) kill (i, 9);
> Ok. This doesn't get him out of the chrooted environment, but you can
> see that having root in a chrooted environment is almost as powerful
> as non-chrooted. A chrooted environment should be so minimal that the
> chances of your users becoming root in there are minimal. -- REW]
Ok, so it's been proven that root inside a chroot() is still dangerous; So
how about adding the ability to have a whole virtual system? Or at least
have some method of denying access to other parts of the system for
chroot()'d processes. So, important system calls could be modified thus:
int kill(*int pid_to_kill)
{
if(caller_pid->fs_root != "/")
{
return(xx);
} else {
.
.
.
}
}
or something like that... Note, I'm not a great coder, and have not messed
with kernel internals... Don't know if this is practical or not. But it
should be possible to deny certain system calls for chroot()ed root
processes. So, if you added some code to mknod(), kill(), exec(), mount()
etc you could plug most (if not all) of the problems with chroot() jails.
Any thoughts on how practical this is?
[mod: We thought about this, and always Linus could come up with
another way to break out of the "jail". Feel free to delve in and
make a complete kernel patch, but Linus is not easily convinced.
Linus' argument was that since there are thousands of ways to break
out, we can't plug-em-all. Just keep your users inside the jail
non-root. --REW]
