About this list Date view Thread view Subject view Author view Attachment view

From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Tue 03 Dec 2002 - 22:56:01 GMT


On Tue, 3 Dec 2002 21:13:03 -0500, Nick Craig-Wood wrote
> On Tue, Dec 03, 2002 at 02:39:35PM +0000, John Goerzen wrote:
> > It's much better if it's first been in some other tree for awhile --
> > say the ac series. Linus trusts that sort of code more.
>
> I don't think that AC (or any other kernel maintainer) would ever
> accept the chmod 000 hack to stop chroot escapes. Its just horrid!

But so simple

> AC has expressed strong opinions on not modifying the current
> semantics of chroot to "fix" them too as it breaks current
> applications.
>
> I think that this needs careful thought before vserver goes for the
> mainline kernel. Perhaps a new system call is needed - one based on
> the BSD chroot maybe but called something else?

What about a new syscall working like chroot but with the following extra

The syscall fails if

        -There are opened file handles which are directories
        -The current working directory is not the same as the argument

Or we can drop the second requierement and use the current working directory
as the new root, so the system call would be parameter-less and even simpler
since we will simply copy one pointer over an other, no parameter validation at
all.

We need a good name for the system call. chrootsafe() ?

The system call would have another effect. It will record the new root
in two places in the process. One is the current root of the process and the
other is the unbreakable root. The idea is that chroot may still be used
inside a chrootsafe() world and the weakness in chroot() may be used to
break chrootsafe() as well. So this unbreakable root would be used as a test
where the horrid 000 test is currently done.

In fact, the unbreakable root could be the parent of the new root.

This seems very easy to implement and would please everyone. It also
enable vservers inside vserver. the current chmod 000 works both ways
and prevent a vserver to enter the vservers it would have created.

So any comment on chrootsafe(). Looks very easy

---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 13 Dec 2002 - 03:49:14 GMT by hypermail 2.1.3