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 [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver