Patchwatcher security improvements
vit.hrachovy at sandbox.cz
Wed Sep 10 07:06:59 CDT 2008
Francois Gouget wrote:
> On Mon, 8 Sep 2008, Ambroz Bizjak wrote:
>> I've abandoned my chroot aproach to improving security in patchwatcher.
>> Instead I've implemented the ability to run untrusted code as a user
>> different than the one running patchwatcher. This is because creating a
>> chroot where Wine could be compiled and tested proved to be too difficult
>> and platform-dependent.
> This seems like an almost perfect task for a virtual machine:
> * set up you virtual machine to taste
> * take a snapshot
> * to test a patch, fire up the virtual machine
> * have it test the patch
> * after the test or when it times out, revert it to the snapshot
> * rinse (done in the step above), repeat
> This could be done with VirtualBox, but maybe other alternatives based
> on Xen or KVM or some such would be better. The main issue I see with
> this is that the OpenGL / DirectSound tests will not run on the real
> hardware (as usual), but maybe a Xen-like approach could help there.
> It would also make it easy to test on FreeBSD / Solaris, at least if
> based on something like VirtualBox (not sure about the Xen-like
Yep. Virtualizaion has 3D shortcomings.
I can see the way how to use pbuilder/pdebuild toolchain on dedicated
user account in Debian to automate this in pretty safe and easy way.
pbuilder uses fakeroot/chroot for this and its use is a nobrainer,
hellish easy and effective.
But this is limited to Debian systems only.
Positive is that we still have access to 3DHW (although not
Anybody has experience with User-mode Linux kernels for that?
Another environment is OpenSolaris.
There we can leverage technologie of zones & ZFS for cheap
pseudovirtualization and fast FS recovery using FS snapshots.
IMO there is no silver bullet to bite all problems on all OS.
We can build OS-specific toolchains around patchwatcher and I think
that's more viable alternative.
More information about the wine-devel