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

On 7/22/07 3:07 PM, "Anthony Liguori" [off-list ref] wrote:

Joshua Brindle wrote:

quoted

James Morris wrote:
  

quoted

On Sat, 21 Jul 2007, Anthony Liguori wrote:

    

quoted

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?

There will be some cases where VMs of different integrity levels have
file:read permissions in common for certain files, for example, shared
libraries, or other resources which may be explicitly shared.

The vm:entrypoint is similar in nature to the file:entrypoint permission.
For files, only a certain trusted codebase is authorized in policy as an
entrypoint into a certain domain; this codebase is given file:entrypoint
permission wrt the target domain.  Similarly, for virtual machines, it would
be nice to authorize in policy a certain disk image as an entrypoint into a
certain domain.  It would also be nice to have SELinux policy decide which
domain a VM will execute in not only based on the type of the virtual disk,
but on the type of the process loading the virtual disk.  This can be
accomplished using the vm:entrypoint permission and type_transition rules.
If the patch that I posted is moved to libvirt, no modification of qemu is
necessary, and those wishing to use qemu (and likely other userspace
backends later) would just link against libvirt and libselinux.

Thanks,

David Windsor

Regards,

Anthony Liguori

quoted

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/