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:55:46AM -0600, John Goerzen wrote:
> On Fri, Dec 13, 2002 at 10:37:20AM -0500, Matt Zimmerman wrote:
> > - 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.
My interpretation of the documentation was that it simply did not allow
processes in different contexts to see each other, but they shared a PID
space. Is this incorrect? (i.e., could there be two processed with PID 1?)
> > - 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)
>
> > 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.
>From what I see, they seem to rely on 1) capabilites, and 2) this mode-000
patch. I am not certain that this combination closes all publicly known
chroot escapes, much less all possible ones. Their FAQ:
http://www.solucorp.qc.ca/howto.hc?projet=vserver&id=62
seems to only address two common methods; I do not know that anyone has even
investigated whether further escapes from vserver are possible.
Security concerns aside, I'd like to see someone implement similar ideas in
vserver alongside what I want to do with UML, to see how they compare in
practice.
--
- mdz
Reply to: