linux security - May 1997 - Re: root in a chroot jail (was: Buffer Overflows: A Summary)

Martin Pool wrote:
>
> > From: Stefan Monnier
<monnier+/news/lists/linux/security@TEQUILA.SYSTEMSZ.CS.YALE.EDU>
> > Date: 05 May 1997 12:23:05 -0400
>
> > [mod: Yes. One "catchall" would be to modify
"suser()" to return
> > (uid==0) && (current->root == THE_ROOT). That would make a
uid==0 in a
> > chrooted environment just another user. Just with a special uid. But
> > still you would have to review the WHOLE system to be sure that no
> > holes remain.... --REW]
>
> I suppose this would contribute to a defense in depth.  But it
doesn''t
> really solve the current problem: that root inside a jail is insecure.
>
> Presumably, if programs in the jail don''t need root privileges,
the
> design will (attempt to) ensure there is no way to get them: nosuid
> mounts, and so on.  The tricky thing is to get a program to run as
> root but remain securely inside a jail.
One of the uses for a root-safe chroot would be to allow users
full shell accounts on that chrooted environment and allow them
to hack all they want, because they can only become "root" in that
chrooted environment.
> The catchall idea wouldn''t, IMHO, achieve this, because presumably
> process needs some of the privileges which depend on suser().
Completely correct.
> Perhaps the kernel could apply these special conditions only to the
> system calls which would help an intruder break out of a jail: perhaps
> access to physical devices would be prohibited, but the task could
> access the whole chroot''d file system.  I can imagine that it
would be
> hard to be sure that all the possible holes were covered.
Right. That is the reason that a catchall solution is better than
blocking just some calls. The work involved in checking everything
is quite serious and error-prone work. A single error is fatal to
the purpose....

					Roger.

>
> --
>   Martin Pool, Pharos Business Solutions      <m.pool@pharos.com.au>
>