Re: xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Wed, Nov 24, 2004 at 10:54:35AM -0500, Stephen Smalley wrote:
> On Wed, 2004-11-24 at 10:49, Luke Kenneth Casson Leighton wrote:
> >  okay, regarding the second argument to avc_has_perm(),
> >  i asked the nice xen developers if it'd be possible to
> >  associate a sid with each virtual machine.
> > 
> >  i mean, if nothing else, it's a matter of grabbing the
> >  number (id) of the xen machine being contacted and faking up
> >  a sid - sprintf(sid, "xen_vm_%d_t", xen_id);
> > 
> >  which is pretty yuk.
> > 
> >  how would i go about _not_ hacking something like that up?
> > 
> >  how would it be possible for the xen master machine to create
> >  a sid per xen machine?  xen_vm_0_t, xen_vm_1_t etc.
> 
> I'm not clear on how you intend to use these distinct security contexts
> (and let's not confuse them with SIDs), particularly for the management
> interface.  You are applying a check as to whether a given process on
> the master can perform a given control operation; in what case would you
> need to distinguish on a per-VM basis?
 
  example:

 a certain user is allowed to shut down and restart the virtual
 machine which is running the SQL server.

 but they most certainly must NOT be allowed to shut down
 the xen master machine, because if they did that, _all_ of the
 virtual machines would be shut down as well.

 another user is allowed access to the console of oh i dunno,
 a virtual machine running a curses-based sales / invoicing
 system (which incidentally accesses the SQL server of another
 virtual machine, above).


> Now, if you want to control interactions among the VMs or access by a VM
> to a resource, that is another matter, 

 yes, i would envisage that being an option - at some later date.

> but I'm not clear that is going
> to be visible to SELinux at all.  

 ?

> IIUC, with NetTop/VMWare, there was a
> process on the host OS for each VM and the host OS was used for access
> to files, devices, etc, so SELinux on the host could associate a
> different domain with each of those processes and control their access
> to files, devices, etc.  But I don't think the situation is the same
> with Xen.

 the way that xen works, shared memory is used as an inter-vm
 communication mechanism, where xen is running in x86 ring
 0, and it arbitrates / manages that communication.
 
 btw everything else (all guest OSes) run in x86 ring 1
 (or 2 or 3 if the guest OS is so inclined).

 there is no locking on that shared memory, such that it becomes
 necessary to have a single application running on one of the VMs (and
 the xen developers have naturally chosen the first xen domain to do
 that) and that application, called xend, manages the locking.

 so i think i am right in saying that it would be necessary
 for each guest OS to enforce the access to that shared
 memory section.

 which is one of the reasons why it is very necessary to let selinux
 have a say in what is allowed to start up new xen guest OSes.
 
 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.