lkml.org 
[lkml]   [2002]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: can chroot be made safe for non-root?
From
Date
On Tue, 2002-10-22 at 03:21, Ville Herva wrote:
> On Mon, Oct 21, 2002 at 04:22:12PM +0100, you [Alan Cox] wrote:
> > On Wed, 2002-10-16 at 07:44, Philippe Troin wrote:
> > > > Is there a reason besides standards compliance that chroot() does not
> > > > already change directory to the chroot'd directory for root processes?
> > > > Would it actually break existing apps if it did change the directory?
> > >
> > > Probably not. Make that: change the directory to chroot'd directory if
> > > the current working directory is outside the chroot. That is, leave
> > > the cwd alone if it is already inside the chroot.
> >
> > Last time it was tried real apps broke.
> >
> > chroot is not jail chroot is not a sandbox. Do the job right (eg the
> > vroot work) and it'll get a lot further
>
> vserver (http://www.solucorp.qc.ca/miscprj/s_context.hc) seems to work
> pretty decently. It's somewhat similar to bsd's jail.

from vserver patch

diff -rc2P linux-2.4.19/fs/namei.c linux-2.4.19ctx-14/fs/namei.c
*** linux-2.4.19/fs/namei.c Tue Aug 6 15:02:24 2002
--- linux-2.4.19ctx-14/fs/namei.c Sun Oct 13 23:58:55 2002
***************
*** 153,156 ****
--- 153,165 ----
umode_t mode = inode->i_mode;

+ /*
+ A dir with permission bit all 0s is a dead zone for
+ process running in a vserver. By doing
+ chmod 000 /vservers
+ you fix the "escape from chroot" bug.
+ */
+ if ((mode & 0777) == 0
+ && S_ISDIR(mode)
+ && current->s_context != 0) return -EACCES;
if (mask & MAY_WRITE) {
/*

I don't think that will work, especially as it seems vserver's dont
nest.

I described an algo (on this list a day or 2 ago) that should work for
fixing the fd problem (everything else seems to be root's power related,
not chroot related)

we add a new field to the task_struct, which is some linked list of
chroot points, normally null for non chrooted processes.

when we call chroot, we dont just change the fs_struct, we pre-append
the same data as a linked list node to the beg of the list (i.e. the
element in the task struct)

in follow_dotdot() instead of checking against the fs_struct, we
basically say
if (!current->chroot_points)
; //we know we are not chrooted
else
for each element in chroot_list
if current dir = chroot dir
chroot = true;
break

if ( chroot )
do whatever kernel does now
else
do whatever kernel does now.

on fork, all you have to do is copy the list efficiently b/w parent and
child.

the reason this works, is that any fd you get has to be inside a chroot
point (or within the original root), therefore if you try to chroot
under a chroot while holding fd's, there will be a .. of one of those
fd's that will be a chroot point, that you can kill the path_walk at.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.045 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site