From: Bodo Eggert (7eggert_at_gmx.de)
Date: Sat 29 Nov 2003 - 10:01:58 GMT
On Wed, 26 Nov 2003, Jacques Gelinas wrote:
> On Wed, 26 Nov 2003 02:55:02 -0500, Enrico Scholz wrote
>
> > Please not that the current 'chmod 000' hack is not affected by this
> > attacks since it is a fixed barrier which can not be bypassed.
> >
> > Therefore, it will not make sense to hope on a magic chrootsafe() syscall
> > for vservers. Alternative approaches like CLONE_NEWNS in combination with
> > pivot_root() or 'mount --rbind <vdir> /' (suggested by Rik van Riel) must
> > be investigated to find better methods.
Wouldn't this require mount-capabilities in vservers to allow nested
vservers? And would it protect against malicious applications sending fds
to each other?
> What about using a new attribute (instead of 000) to tag a directory permanently
> as a barrier.
I was thinking about keeping a (fixed-size?) list of (device,inode)s,
allocated at the first chrootsafe. This would allow 512 levels of
chrootsafe per 4k of allocated memory. I think this should be enough.
Off cause, this would not prevent malicious_app1 in chroot(a) to send
an fd to malicious_app2 in chroot(b), but an additional check in the
fd-passing-routine might do the trick.
I think it should be enough to allow directory-fd-passing only if the ctx
matches (or the sender is in a "magic" or parent ctx?) and all
chroot-points from the sending application are also included in the
receiver's chrootsafe-list. The receiver may still escalate it's
privileges (as usural, as long as fd passing is allowed), but the effect
should be limited to the sender's chroot and the combined privileges of
the malicious processes. (It is, isn't it?)
If directory fd passing is completely disabled, it shouldn't even be
possible to access files being in one chroot but having only access
permissons for uid/gid of another chrooted process. (This might especially
be important if a chrooted uid0-process was exploited as well as a user
account.) Maybe there should be an option to do this, too.
BTW: If no account is limited by a restricted shell and restrictions in
global config files, would allowing users =! root to chrootsafe as
decribed above be a security risk (asuming it includes chdir($newroot))?
--
¤ Bill of Spammer-Rights ¤
1. We have the right to assassinate you.
2. You have the right to be assassinated.
3. You have the right to resist, but it is futile.
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver