Re: Automated package testing (Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?)
On Fri, Dec 13, 2002 at 10:37:20AM -0500, Matt Zimmerman wrote:
> I had looked at vserver before, but the description is not very informative and
> I got the impression that it only handled the issue of sockets. I see now that
> it also tries to prevent the processes from seeing each other. I still see
> these advantages to UML:
>
> - entirely separate process table with its own working init(1), so full
> system startup and shutdown can be tested, as well as init itself
vserver provides this as well, with the exception that it does not provide
virtual consoles for init.
> - shareable, copy-on-write block devices (makes repeated testing much more
> efficient)
vserver provides some sort of support for copy-on-write filesystem trees,
but it always seemed like an unnecessary kludge to me, so I didn't bother
with it.
The others I agree with.
vserver, then, has these advantages:
- faster execution
- can have direct access to the hardware on the host machine if so desired
(restricted by capabilities and what files are present in /dev)
- less kludgy networking setup (though it still is a bit kludgy, but
UML gave me no end of troubles)
> As a side note, this paragraph in the vserver documentation makes me
> uncomfortable:
>
> > Non reversible isolation
> >
> > Unix and Linux have always had the chroot() system call. This call was
> > used to trap a process into a sub-directory. After the system-call,
> > the process is led to believe that the sub-directory is now the root
> > directory. This system call can't be reversed. In fact, the only thing
> > a process can do is trap itself further and further in the file-system
> > (calling chroot() again).
>
> Unless their kernel patch changes the semantics of chroot() and a bunch of
> other things, this is not at all true, and it is trivial to break out of a
> chroot given root access.
If I understand correctly, they have not changed the semantics of chroot()
but have instead introduced new system calls that are used to implement the
features that are necessary. There is a new chbind() system call that
restricts that network ports a process can bind to (and it is
non-reversible) and a context system that isolates processes and the like
from each other.
The vserver system is pretty careful about executing things exactly right,
and combined with permissions set to 000 of the parent directory of the
chroots and reduced capabilities for child contexts, they seem to have
accomplished what they claim without altering the semantics of chroot().
I have not looked at the code in any detail, but I can vouch for the common
attacks (cd .. for instance) not working.
Also note that because of the context system, the /proc in the chroot
environment is not a full /proc -- it shows only the processes in that
context, not all the processes on the system.
This was recently discussed on the mailing list, so you may want to check in
over there.
-- John
Reply to: