Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Joshua Brindle wrote:
> James Morris wrote:
>   
>> On Sat, 21 Jul 2007, Anthony Liguori wrote:
>>
>>     
>>> Can you already write an selinux policy that changes the label of a
>>> process when it open()s a different file?
>>>       
>> No, and you normally want to do this over an exec anyway, to
>> ensure the new execution state is clean.
>>
>>     
>
> This is correct and the object model being proposed isn't just about
> opening files. 
>
> Anthony - There are several userspace object managers for SELinux,
> basically they manage resources that are too abstract for the kernel to
> manage. These include DBUS connections, X windows/pixmaps/cursors/etc,
> postgresql tables and rows, etc. SELinux is designed to designed to have
> non-centralized enforcement of the policy (but centralized decision
> making). In this case the object model isn't just about opening a file,
> its about lauching and restricting a vm based on an abstract resource,
> in this case a virtual disk file, that the kernel can't differenciate
> from any other file.
>
> The reason for this abstraction is simple, think about all the files
> that qemu has to open that aren't disk files. For example, if you have 3
> vm's, unclass, secret, top secret, those qemu processes still have to
> share resources, library files, configuration files, devices,
> potentially log, pid etc. If someone could manage to get a top secret
> disk labeled lib_t they could boot any of those vm's with that disk
> image (using snapshot or some feature to prevent write attempts on it),
> and disclose top secret data where it shouldn't be disclosed. 
>   

The only way that the VM could possible see the top secret data is if 
the disk file was readable by the QEMU process running the secret 
guest.  That's the security problem.  You address this "attack" by 
simply not letting the user that launched the QEMU process have read 
access to the top secret disk file.   Why would you ever want to allow 
the QEMU process that's running a "secret" domain to have any read 
access to top secret files?

Regards,

Anthony Liguori

> With David's object model this kind of attack can be prevented because
> virtual disk files aren't 'just files' to qemu, they are an abstract
> resource that means more than just a regular file, just like a database
> file is more than just a regular file for SE-Postgresql.
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/