re: [Vserver] chroot(safe) issues
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 /' (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
re: [Vserver] chroot(safe) issues
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 /' (suggested by Rik van Riel) must > be investigated to find better methods. What about using a new attribute (instead of 000) to tag a directory permanently as a barrier. I have tried that a while ago to get rid of the problems with 000. I was looking for a way to prevent access to .. while providing forward access. Did not find anything. too bad for chrootsafe. - Jacques Gelinas <[EMAIL PROTECTED]> vserver: run general purpose virtual servers on one box, full speed! http://www.solucorp.qc.ca/miscprj/s_context.hc ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] chroot(safe) issues
> > 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 /' (suggested by Rik van Riel) must > be investigated to find better methods. > I say Rik and Herber - vserver _can`t_ use CLONE_NEWNS and pivot_root because some nmaped files be placed at old root and old root can`t be unmounted. If you have use separated namespace you must write own function to create namespace and fill data. after it process migrate to it. It need modification at kernel but i can`t find other way for correctly work with namespace. If interested see may snapshots. -- With best regards, Alex ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] chroot(safe) issues
Hello,
on IRC two days ago we had a discussion about secure chroot()
implementation. To make it short: it does not exist a such one.
The details: the problem of current chroot(2) is that this syscall is
not stackable -- on every new chroot(2) invocation the dead zone will be
set to a new value and the old one dropped. This fact allows to bypass
the chroot by moving into an "free" directory with 'fchdir(fd)' and go
from there with subsequent 'chdir("..")' to the real root.
A vserver kernel-patch introduced a new chrootsafe() syscall which
tries to prevent the 'fchdir()' part by forbidding open directories as
chrootsafe() time. So, the 'fchdir(fd)' can not be executed.
Sounds really good and secure on first glance, but kloo_ brought in the
idea to transfer filedescriptors via SCM_RIGHTS -- and it works; see
http://www.tu-chemnitz.de/~ensc/chrootescape.c
(replace vc_chrootsafe() with your own implementation; the actual
program uses an experimental syscall which was written by Herbert
Poetzl to demonstrate the issue).
In attack-mode, this program forks into two processes. The first one
calls vc_chrootsafe() to move the dead zone. The second process opens a
directory-filedescriptor and transmits it to the first process through
SCM_RIGHTS. Now, this process can continue with conventional chroot()
methods to come to the real /.
Assuming stackable chroots (every chroot() puts the new dead zone into a
list which gets processed in vfs_permissions()), the SCM_RIGHTS method
can bypass these chroot() also. All you need are two processes within
independent chroots which are sharing a filesystem (e.g. /home). The
first process moves into the environment of the second one with the
already mentioned fchdir() method. Now, it can be moved freely to '..'
since the dead zone does not exist there.
Another method to escape chrootsafe(), would be the movement of the
current directory: one process calls chrootsafe() to move the dead zone,
and goes into a directory within the new jail. Now, a second process
(started within the old dead zone) moves this directory to a place which
is outside of the new dead zone. The cwd-fd of the new process stays in
this dir, and on the path to the real '/', the new dead zone will never
be reached.
Under some circumstances (two processes in independent chroot environments
which are sharing a filesystem), this attack works for ordinary users
also.
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 /' (suggested by Rik van Riel) must
be investigated to find better methods.
Enrico
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
