selinux breaks revisor

[Douglas McClendon]

Jesse Keating wrote:
> On Thu, 24 Jan 2008 23:24:17 +0000
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
>> On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote:
>>> On Thu, 24 Jan 2008, Daniel P. Berrange wrote:
>>>
>>>>> Something to consider perhaps is the use of lguest, which is
>>>>> currently i386 only, but does boot up nearly instantaneously,
>>>>> and can be scripted, as its console is the launching shell.
>>>>>
>>>>> Is there an efficient technique for mounting a disk image so
>>>>> that changes made to it are discarded?
>>>> Sure, just create an LVM writable snapshot of your master image,
>>>> and boot with that instead, and throw away the snapshot when
>>>> you're done.
>>> Cool.  So if there was a RPM package which contained a barebones
>>> Fedora image and some management scripts, I don't imagine it would
>>> be too difficult to do things like build RPMs inside that with e.g.
>>> different SELinux policies to the host.  Any supporting RPMS
>>> required inside the guest could be installed via a script either
>>> from host media or over the net, then the final RPM (or whatever is
>>> being created) could be copied back out to the host before
>>> discarding the guest instance.
>>>
>>> It would not be as fast or simple as chroot, but I suspect it would
>>> work pretty well, especially if the guest dispenses with all
>>> non-essential startup.
>> Actually you can do some tricks here too. You can boot the guest using
>> the real disk image. Once it is up & running in desired state you can
>> save the VM to disk (cf hibernate).  Launching it just becomes a case
>> of taking a snapshot of the disk, and restoring the VM state file.
>> Much much quicker than normal startup - a matter of seconds -
>> depending on guest RAM  size. As long as you take care to always
>> restore it against a snapshot of the disk from the same it was saved,
>> you can repeat this restore process many times over. It is not
>> entirely straightforward to do these steps in the general case, but
>> if you want to mandate LVM storage only then it is a tractable problem
>>
>> Dan.
> 
> 
> Yeah, it all sounds pretty exciting, but get back to me when it works
> on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha...
>

*cough* viros *cough* smirfgen *cough* qfakeroot

No, doesn't work on those archs, by since all the infra is qemu, it may 
well get there in the foreseeable future.

Basically smirfgen is my version of mkinitrd/mayflower, but in addition 
to generating initramfss that boot livecds, it generates ones which do 
nothing but set up sandbox so that qfakeroot can boot them up via qemu 
attached to one disk image used for input, one used for output (gets 
detarred), and one for scratch space, and one to optionally connect to a 
real disk device or image.  There is also an option to automatically 
make that last one get a devicemapper snapshot layer of protection (same 
thing as the lvm described, but at a lower more generic layer).

And qemu gets used in nographic with console going to tty which goes to 
stdout (redirected internally).

The result is that it takes about a couple minutes to convert an 
arbitrary tarball to an ext3 filesystem image.  (longer for bigger input)

Currently it pulls in a copy of the host's selinux policy to use, though 
it is pretty trivial to make that an option to disable, or pull in an 
arbitrary selinux policy.

Still very alpha, but maybe interesting to consider

http://viros.org

-dmc