I am eager to be able to sandbox my processes on a system without the
help of suid-root programs (as I prefer to have none of these on my
system).
Would it be reasonable to allow non-root processes to chroot(), if the
chroot syscall also changed the cwd for non-root processes?
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?
-Eric
(who wishes there were better ways to run untrusted code)
Eric Buddington <[email protected]> writes:
> I am eager to be able to sandbox my processes on a system without the
> help of suid-root programs (as I prefer to have none of these on my
> system).
Probably an impossible task...
> Would it be reasonable to allow non-root processes to chroot(), if the
> chroot syscall also changed the cwd for non-root processes?
No.
fd = open("/", O_RDONLY);
chroot("/tmp");
fchdir(fd);
and you're out of the chroot.
> 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.
Phil.
Philippe Troin wrote:
>Eric Buddington <[email protected]> writes:
>> Would it be reasonable to allow non-root processes to chroot(), if the
>> chroot syscall also changed the cwd for non-root processes?
>
>No.
>
> fd = open("/", O_RDONLY);
> chroot("/tmp");
> fchdir(fd);
>
>and you're out of the chroot.
Irrelevant. If a process *wants* to voluntarily sandbox itself, it can
close all open file descriptors before sandboxing.
Please note that
chroot("/tmp");
fd = open("/", O_RDONLY);
fchdir(fd);
does *not* let you escape from the sandbox. This means that a process
can sandbox itself, and once sandboxed, it can no longer escape.
This functionality would be very useful for security purposes (see, e.g.,
"privilege separation").
It is true that there are some tricky issues here. For instance, root
has many ways to escape from a chroot() jail, so you should never use
chroot() to confine processes running as root. Also, if non-root users
can call chroot(), then there may be bad interactions if the chroot-ed
process later calls chroot() again, or execs a setuid program.
However, I believe all of these tricky issues can be dealt with. See, e.g.,
http://www.cs.berkeley.edu/~smcpeak/cs261/index.html
Eric Buddington wrote:
>Would it be reasonable to allow non-root processes to chroot(), if the
>chroot syscall also changed the cwd for non-root processes?
It might be reasonable. It is a little bit tricky, as if you're not
careful, this can open up security holes. However, one course project
in a class I taught two years ago proposed a way to safely allow non-root
processes to use chroot(). Look here:
http://www.cs.berkeley.edu/~smcpeak/cs261/index.html
You might also be interested in the LSM project; in sandboxes like
SubDomain, Janus, SELinux, systrace, and the like; in privilege separation;
in OpenBSD's jail(); and similar topics.
>(who wishes there were better ways to run untrusted code)
Me, too.
[email protected] (David Wagner) writes:
> Philippe Troin wrote:
> >Eric Buddington <[email protected]> writes:
> >> Would it be reasonable to allow non-root processes to chroot(), if the
> >> chroot syscall also changed the cwd for non-root processes?
> >
> >No.
> >
> > fd = open("/", O_RDONLY);
> > chroot("/tmp");
> > fchdir(fd);
> >
> >and you're out of the chroot.
>
> Irrelevant. If a process *wants* to voluntarily sandbox itself, it can
> close all open file descriptors before sandboxing.
You missed the point.
If the process can be forced to run the above (possibly via a stack
overflow), then it is out of the chroot.
Phil.
Philippe Troin wrote:
>[email protected] (David Wagner) writes:
>> Philippe Troin wrote:
>> > fd = open("/", O_RDONLY);
>> > chroot("/tmp");
>> > fchdir(fd);
>> >
>> >and you're out of the chroot.
>>
>> Irrelevant. If a process *wants* to voluntarily sandbox itself, it can
>> close all open file descriptors before sandboxing.
>
>You missed the point.
>
>If the process can be forced to run the above (possibly via a stack
>overflow), then it is out of the chroot.
Ahh, yes. Exactly so. My apologies for missing your point.
Still, I don't think this is a big deal. The problem is that if
a chroot-ed process can call chroot() again, it can escape from the
chroot jail. There is one obvious solution: simply don't allow chroot-ed
process to call chroot() again. This is addressed in the link I posted
previously.
So I still think that chroot() could plausibly be made safe for non-root
users.
>I am eager to be able to sandbox my processes on a system without the
>help of suid-root programs (as I prefer to have none of these on my
>system).
>Would it be reasonable to allow non-root processes to chroot(), if the
>chroot syscall also changed the cwd for non-root processes?
You might want to look into systrace, see
http://www.citi.umich.edu/u/provos/systrace/
Sandboxing your own applications does not require special privileges.
Policy generation is intuitive and interactive. Thats means you can
generate your policies on the fly without complete knowledge of the
exact code paths an application takes. (I run all my 3rd-party
software and most system daemons under systrace)
Policy violations are reported and can be resolved directly in
interactive mode.
To avoid setuid-root programs, systrace supports Privilege Elevation.
This is a novel feature that allows you to run an application without
special privileges. The policy can momentarily elevate the privileges
of the application, for example to bind a reserved port or to create a
raw socket. Basically, it allows as fine grained capabilities as
possible.
The Linux port is basically finished and should appear on the web page
in the next couple days.
Niels.
Hi!
> I am eager to be able to sandbox my processes on a system without the
> help of suid-root programs (as I prefer to have none of these on my
> system).
You can do that using ptrace. subterfugue.sf.net.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel Machek wrote:
>> I am eager to be able to sandbox my processes on a system without the
>> help of suid-root programs (as I prefer to have none of these on my
>> system).
>
>You can do that using ptrace. subterfugue.sf.net.
ptrace() is ok, but it also has lots of disadvantages: performance,
expressiveness, security, assurance. I've posted before on this mailing
list, at length, about them. In short, ptrace() is not an ideal solution,
and a secure chroot() or other way to construct a jail/sandbox would
be better. (LSM will be much better.)
On Fri, 2002-10-18 at 16:14, David Wagner wrote:
> Pavel Machek wrote:
> >> I am eager to be able to sandbox my processes on a system without the
> >> help of suid-root programs (as I prefer to have none of these on my
> >> system).
> >
> >You can do that using ptrace. subterfugue.sf.net.
>
> ptrace() is ok, but it also has lots of disadvantages: performance,
> expressiveness, security, assurance. I've posted before on this mailing
> list, at length, about them. In short, ptrace() is not an ideal solution,
> and a secure chroot() or other way to construct a jail/sandbox would
> be better. (LSM will be much better.)
the problem with chroot() is that they dont nest. If you get an fd
outside the chroot, you effectively broke the chroot. Therefore, if
someone can get root inside the chroot, all they have to do is open an
fd, chroot somewhere else, then fchdir to that fd.
If however, one could provide even a single level of nesting, such that
a chroot outside of a chroot sets the first level, and any other chroot
after that sets the inner level, then even root wouldn't be able to
break out of the chroot (presuming it didn't bring any fd's into the
chroot w/ it).
It might be nice to provide even more levels than this, but not sure if
one gain much by doing that and the add complexity might make it not
worthwhile. Then again, even 2 levels might be too complex. I've
actually thought a little of this in regards to some research I'm doing,
but haven't had a chance yet to persue, and see what would need to be
effected. It would seem to come into play mostly on the path walking
algorithms, but that's from a very very cursory reading of the stuff.
anyone else have any ideas on this? Or am I crazy :)
thanks,
shaya
Shaya Potter wrote:
>the problem with chroot() is that they dont nest.
That's *a* problem, but not (IMHO) the most significant problem.
The biggest disadvantages with chroot() (as I see it) are:
* not useable unless you're root
* too coarse-grained
* only protects the filesystem, but not other resources (e.g., the network)
* not suitable for jailing root
> If however, one could provide even a single level of nesting, such that
> a chroot outside of a chroot sets the first level, and any other chroot
> after that sets the inner level, then even root wouldn't be able to
> break out of the chroot (presuming it didn't bring any fd's into the
> chroot w/ it).
This is not quite right. There are LOTS of other ways that root
can break out of a chroot.
Actually, I suspect that nested chroot()s may not be needed very
frequently, so I think a simpler approach may be simply to prevent
a chrooted process from calling chroot() again: i.e., prevent nesting.
On Fri, 2002-10-18 at 17:00, David Wagner wrote:
> Shaya Potter wrote:
> >the problem with chroot() is that they dont nest.
>
> That's *a* problem, but not (IMHO) the most significant problem.
> The biggest disadvantages with chroot() (as I see it) are:
> * not useable unless you're root
is this a problem from a security perspective, or a design perspective.
i.e. users should be able to chroot their processes, not to gain
security but just to be able to do things. Or also for security?
> * too coarse-grained
what exactly do you mean?
> * only protects the filesystem, but not other resources (e.g., the
network)
yes, chroot doesn't make a jail, but chroot + other stuff can make a
jail, and chroot can give you the fs side for close to free (lost
performance that is)
> * not suitable for jailing root
b/c root can break out easily, right? to jail root you need other stuff
as I said above.
>
> > If however, one could provide even a single level of nesting, such
that
> > a chroot outside of a chroot sets the first level, and any other
chroot
> > after that sets the inner level, then even root wouldn't be able to
> > break out of the chroot (presuming it didn't bring any fd's into the
> > chroot w/ it).
>
> This is not quite right. There are LOTS of other ways that root
> can break out of a chroot.
how? the class way is the fchdir, but I guess there are others, but my
brain is not seeing them right now.
> Actually, I suspect that nested chroot()s may not be needed very
> frequently, so I think a simpler approach may be simply to prevent
> a chrooted process from calling chroot() again: i.e., prevent nesting.
well, this would prevent you from using chroot w/ processes that want to
chroot (running an ftpd inside of a chroot, dont some like to chroot for
anonymous access?), I've thought about that in regards to my research
related to our zap system, and I would rather not have to do that.
On Tue, Oct 15, 2002 at 11:44:32PM -0700, Philippe Troin wrote:
> > Would it be reasonable to allow non-root processes to chroot(), if the
> > chroot syscall also changed the cwd for non-root processes?
>
> No.
>
> fd = open("/", O_RDONLY);
> chroot("/tmp");
> fchdir(fd);
>
> and you're out of the chroot.
I see. From my aesthetic, it would make sense for chroots to 'stack',
such that once a directory is made the root directory, its '..' entry
*always* points to itself, even after another chroot(). That would
prevent the above break (you could be outside the new root, but you
still couldn't back out past the old root), though perhaps at an
unacceptable in complexity.
I do like the idea of preventing multiple chroots, as a second option.
Thanks to everyone for all the useful comments.
-Eric
In article <[email protected]> you wrote:
> I do like the idea of preventing multiple chroots, as a second option.
this is not enough to allow chroot for non root. There are just too many
suid programs which rely on absolute path. So if one allows chroot() for
non-root users, the usage of suid/sgid must be forbidden, too.
Greetings
bernd
On 2002-10-19, Eric Buddington <[email protected]>
wrote:
> On Tue, Oct 15, 2002 at 11:44:32PM -0700, Philippe Troin wrote:
> > > Would it be reasonable to allow non-root processes to chroot(), if
> > > the chroot syscall also changed the cwd for non-root processes?
> >
> > No.
> >
> > fd = open("/", O_RDONLY);
> > chroot("/tmp");
> > fchdir(fd);
> >
> > and you're out of the chroot.
> I see. From my aesthetic, it would make sense for chroots to 'stack',
> such that once a directory is made the root directory, its '..' entry
> *always* points to itself, even after another chroot(). That would
> prevent the above break (you could be outside the new root, but you
> still couldn't back out past the old root), though perhaps at an
> unacceptable in complexity.
And not quite enough, if I understand your suggestion properly. It's not
necessary above to chroot or fchroot using fd; its existance is enough to
monkey with things outside/above the chroot jail, which is unacceptable.
> I do like the idea of preventing multiple chroots, as a second option.
That's far from enough though. You also must consider:
-signals to non-chrooted processes
-shared memory (maybe obsolete now with shmfs)
-running a setuid file such as /bin/su which has been hardlinked in by
a process outside the jail, reading your bogus passwd file in the jail
(collusion/multifactor attack)
-chmod +s a chrooted file, to be accessed by another, unprivileged UID
which is not jailed (collusion/multifactor attack)
-ptrace non-chrooted processes
-in addition, for root:
-open raw devices / mknod of block and char devices
-mount(2)
-various capabilities need to be dropped (sysctl, module loading, ...)
Any of these allow a chrooted process to interact too much with the rest
of the system, if not leading to outright, immediate chroot-breaking.
Some of them can be protected against without kernel patching, just
careful policing of chroot usage: don't ever chroot a UID who also has
processes outside of chroot (or in a different jail); make the parent of
the chroot dir inaccessible by non-chrooted processes / regular users,
dont't give write access/directory ownership anywhere under chroot, etc.
Some can't be made safe(r) w/o help.
I have a patch to do all of the above here (only for 2.2 atm):
http://www.theaimsgroup.com/~hlein/hap-linux/
Look for CONFIG_SECURE_CHROOT. Double chroots are forbidden, but also, a
warning is printed if a process attempts to chroot with an open fd to a
directory (I decided against making the chroot call fail, as any software
buggy enough to chroot with open directory fds is likely to not check the
return value of chroot(2), and blindly continue on failure--even worse).
I'd be happy to hear about (and fix ;) anything I've missed.
IIRC, FreeBSD allow a chroot'ed process to chroot again if and only if
the
new root is a subdirectory of the initial chroot. This allows things
like
traditional, chrooting anonymous FTP to be run under an initial chroot.
Double-chroot would also be desirable if you wanted to, say, have init
spawn some kind of supervisory daemon (or just /bin/login on a serial
port) and then have *everything* else be chrooted, all multiuser daemons,
etc. Then a compromise can play all they want in the sandbox; you still
have an opportunity for integrity checking tools, etc to run in a
somewhat
trustworthy environment.
--
Hank Leininger <[email protected]>
In article <[email protected]> you wrote:
> directory (I decided against making the chroot call fail, as any software
> buggy enough to chroot with open directory fds is likely to not check the
> return value of chroot(2), and blindly continue on failure--even worse).
> I'd be happy to hear about (and fix ;) anything I've missed.
One idea would be to sigsegv the program which is doing a chroot with open
fds :)
> IIRC, FreeBSD allow a chroot'ed process to chroot again if and only if
> the
> new root is a subdirectory of the initial chroot. This allows things
> like
> traditional, chrooting anonymous FTP to be run under an initial chroot.
well, you can only changeroot in a subdir anyway, so this is not the point
that freebsd is allowing a chroot in a chroot. As far as I know they simply
solved the break out issue.
BTW: kill on open fd would solve the breakout issue, too.
Greetings
Bernd
On Sun, 2002-10-20 at 06:40, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > IIRC, FreeBSD allow a chroot'ed process to chroot again if and only if
> > the
> > new root is a subdirectory of the initial chroot. This allows things
> > like
> > traditional, chrooting anonymous FTP to be run under an initial chroot.
>
> well, you can only changeroot in a subdir anyway, so this is not the point
> that freebsd is allowing a chroot in a chroot. As far as I know they simply
> solved the break out issue.
didn't see the mail this is in response to, but are you talking about
FreeBSD's jail() syscall? or are you talking about chroot() actually
being able to nest?
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
On Sun, Oct 20, 2002 at 05:15:07PM -0500, Rob Landley wrote:
> Anything that wants to look at /etc/password or /etc/shadow comes to mind.
only if it runs with elevated priveledges. If it is started under a users
chroot, the eleated privs come from suid/sgid.
Greetings
Bernd
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.
-- v --
[email protected]
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.
On Saturday 19 October 2002 12:44 pm, Eric Buddington wrote:
> On Tue, Oct 15, 2002 at 11:44:32PM -0700, Philippe Troin wrote:
> > > Would it be reasonable to allow non-root processes to chroot(), if the
> > > chroot syscall also changed the cwd for non-root processes?
> >
> > No.
> >
> > fd = open("/", O_RDONLY);
> > chroot("/tmp");
> > fchdir(fd);
> >
> > and you're out of the chroot.
>
> I see. From my aesthetic, it would make sense for chroots to 'stack',
> such that once a directory is made the root directory, its '..' entry
> *always* points to itself, even after another chroot(). That would
> prevent the above break (you could be outside the new root, but you
> still couldn't back out past the old root), though perhaps at an
> unacceptable in complexity.
That isn't relevent - the fchdir(fd) doesn't use a path. It doesn't matter
what is done to the ".." entry. fd is referring to an OPEN file id. The
chdir goes to the file id, bypassing any path name evaluation.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Tue, 2002-10-22 at 16:15, Shaya Potter wrote:
> 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.
This was just a quick and dirty fix to prevent root in a vserver from
breaking out into the "real server", that's it. chroot() inside a
vserver works exactly the same way as without vservers.
One negative sideeffect is that root in a vserver can't access any
directory with all 0s in the permission bits. But that's better than
having root in a vserver being able to go out into the "real server".
I'm not saying this is a very good solution but I think it at least does
what it's supposed to do in a dirty way.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
On Tue, 2002-10-22 at 11:42, Jesse Pollard wrote:
> On Saturday 19 October 2002 12:44 pm, Eric Buddington wrote:
> > On Tue, Oct 15, 2002 at 11:44:32PM -0700, Philippe Troin wrote:
> > > > Would it be reasonable to allow non-root processes to chroot(),
if the
> > > > chroot syscall also changed the cwd for non-root processes?
> > >
> > > No.
> > >
> > > fd = open("/", O_RDONLY);
> > > chroot("/tmp");
> > > fchdir(fd);
> > >
> > > and you're out of the chroot.
> >
> > I see. From my aesthetic, it would make sense for chroots to
'stack',
> > such that once a directory is made the root directory, its '..'
entry
> > *always* points to itself, even after another chroot(). That would
> > prevent the above break (you could be outside the new root, but you
> > still couldn't back out past the old root), though perhaps at an
> > unacceptable in complexity.
>
> That isn't relevent - the fchdir(fd) doesn't use a path. It doesn't
matter
> what is done to the ".." entry. fd is referring to an OPEN file id.
The
> chdir goes to the file id, bypassing any path name evaluation.
yes, but if the fd is within a chroot, then there will be a ".." above
that will be a chroot point, if you go into the orig chroot w an fd,
yea, you can go up to the "orig root" (aka the real /) from that fd.
Otherwise, you will be stopped once you hit a chroot point.
If you are in a chroot, and you can get chroot's to stack (as per I
described b4) then any fd you ever get will be locked in, as you wont be
able to use fchdir to jump out of all the chroot's and then ".." up.