xen 2.0 - adding selinux permissions

xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton]

i'm considering doing some mods on xen 2.0's management interface,
if i can justify the work.

at present, the xen "master", which is the first virtual machine fired up,
is allowed access to the xen control system (running in x86 ring 0) via
/proc/xen.

some ioctl commands represent things like "start a new virtual machine",
"stop one", "suspend this session to disk" that sort of thing.

then, what the xen developers have done is to write a web
interface (using twisted python *gibber*) which presents
virtually unrestricted (*gibber*) access to that /proc/xen
interface on port 8000, using HTTP.

then there is a command xm which connects to port 8000 and issues
commands over the network port.

apparently it is possible to implement authentication with
the twisted python framework, so it's not _all_ bad - plus,
if you're running a cluster, security restrictions just... get
in the way!!!


what i would _like_ to do is:

- take out the HTTP access and merge the xm http client with the xend
  http server.

- add in some new selinux security ids representing the xen commands
  (create virtual machine, list virtual machines, shutdown a machine,
   suspend-a-session-to-disk, etc.)

- write an selinux policy restricting the xm command to be the only
  thing that is allowed to perform those operations.


so: is this a practical proposition?

i've looked at security/selinux/hooks.c - is it a simple matter of, say,
copying the file ioctl command?

should i be adding a new function to the LSM function table, examining
the xen ioctl kernel call and calling the new security function in the
xen ioctl?

if i add a new function to the LSM function table, then presumably that
means that someone could write a linux "capabilities" function too, yes?

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.

Re: xen 2.0 - adding selinux permissions

[Stephen Smalley]

On Tue, 2004-11-23 at 17:03, Luke Kenneth Casson Leighton wrote:
> - add in some new selinux security ids representing the xen commands
>   (create virtual machine, list virtual machines, shutdown a machine,
>    suspend-a-session-to-disk, etc.)

I assume you actually mean add a new security class (xen) and define an
access vector for it with permissions for each of these operations, not
add a security identifier.  As there is no real object for these
requests, I suppose you could just make them task->self checks as with
the existing capability checks.  No need to add a new security id for
the target.

> should i be adding a new function to the LSM function table, examining
> the xen ioctl kernel call and calling the new security function in the
> xen ioctl?

Yes, you would need to embed the hook in the xen code if you want to
have the desired granularity of control.  Long term, we'd like to have
similar hooks in other drivers and filesystem implementations, but that
wasn't viewed as practical for the initial phase of LSM, where we were
mostly limited to hooks in the core kernel.

> if i add a new function to the LSM function table, then presumably that
> means that someone could write a linux "capabilities" function too, yes?

Yes, but there is no room for expansion of capability definitions
presently, so they would have to just map all xen commands to existing
capabilities.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: xen 2.0 - adding selinux permissions

[Stephen Smalley]

On Wed, 2004-11-24 at 10:09, Luke Kenneth Casson Leighton wrote:
>  okay, i must have misunderstood.
> 
>  i envisage creating a xen_has_perm() and _that_ means adding
>  something to security/selinux/include/av_permissions.h
>  #define XEN_VM_CREATE  0x00000001UL
>  #define XEN_VM_DESTROY 0x00000002UL, etc.
> 
>  and creating a SECCLASS_XEN?

Those header files are automatically generated.  To add new
classes/permissions:
- Check out a copy of linux-2.6 and selinux-usr from our sourceforge CVS
tree,
- cd selinux-usr/policy/flask
- Edit security_classes and access_vectors, adding your new class at the
end.
- Run make in that directory to generate the headers,
- Run make tokern to push the new headers to
linux-2.6/security/selinux/include or copy them manually,
- Build the new kernel and policy that includes those definitions.

And note that until we merge a patch from you reserving that security
class, someone else may come along and take that value away from you at
any time, at which point you'll have to re-base and rebuild.  Actually,
that reminds me to check on the status of such a patch for the
ipsec-related class.

> 	 /* Check whether a task is allowed to perform a xen virtual machine
> 	    operation. */
> 	int xen_has_perm(struct task_struct *tsk, u32 perms)
> 	{
> 		struct task_security_struct *tsec;
> 
> 		tsec = tsk->security;
> 
> 		return avc_has_perm(tsec->sid, tsec->sid,
> 				SECCLASS_XEN, perms, NULL, NULL);
> 	}

Doesn't task_has_xen() sound better? ;)

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton]

On Wed, Nov 24, 2004 at 08:39:16AM -0500, Stephen Smalley wrote:
> On Tue, 2004-11-23 at 17:03, Luke Kenneth Casson Leighton wrote:
> > - add in some new selinux security ids representing the xen commands
> >   (create virtual machine, list virtual machines, shutdown a machine,
> >    suspend-a-session-to-disk, etc.)
> 
> I assume you actually mean add a new security class (xen) and define an
> access vector for it with permissions for each of these operations, not
> add a security identifier.  

 yes?

> As there is no real object for these
> requests, I suppose you could just make them task->self checks as with
> the existing capability checks.  No need to add a new security id for
> the target.

 okay, i must have misunderstood.

 i envisage creating a xen_has_perm() and _that_ means adding
 something to security/selinux/include/av_permissions.h
 #define XEN_VM_CREATE  0x00000001UL
 #define XEN_VM_DESTROY 0x00000002UL, etc.

 and creating a SECCLASS_XEN?

	 /* Check whether a task is allowed to perform a xen virtual machine
	    operation. */
	int xen_has_perm(struct task_struct *tsk, u32 perms)
	{
		struct task_security_struct *tsec;

		tsec = tsk->security;

		return avc_has_perm(tsec->sid, tsec->sid,
				SECCLASS_XEN, perms, NULL, NULL);
	}

 what alternative to this approach is there?


 bearing in mind that the xen daemon (running in the xen master)
 offers access to the consoles of the guest operating systems.

 i _really_ want to be able to stop that access from happening, or
 at least control the circumstances under which access to the
 guest's consoles is allowed!

 at present, any program with access to port 8000 (on localhost or on
 the LAN depending on a config option) can start a guest OS, kill an
 existing one, access all consoles and start hacking away at the login
 prompt, that sort of thing...

 l.


--
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.

Re: xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton]

On Wed, Nov 24, 2004 at 10:06:09AM -0500, Stephen Smalley wrote:
> On Wed, 2004-11-24 at 10:09, Luke Kenneth Casson Leighton wrote:
> >  okay, i must have misunderstood.
> > 
> >  i envisage creating a xen_has_perm() and _that_ means adding
> >  something to security/selinux/include/av_permissions.h
> >  #define XEN_VM_CREATE  0x00000001UL
> >  #define XEN_VM_DESTROY 0x00000002UL, etc.
> > 
> >  and creating a SECCLASS_XEN?
> 
> Those header files are automatically generated.  To add new
> classes/permissions:
> - Check out a copy of linux-2.6 and selinux-usr from our sourceforge CVS
> tree,
> - cd selinux-usr/policy/flask
> - Edit security_classes and access_vectors, adding your new class at the
> end.
> - Run make in that directory to generate the headers,
> - Run make tokern to push the new headers to
> linux-2.6/security/selinux/include or copy them manually,
> - Build the new kernel and policy that includes those definitions.

 ack.

 
> > 	 /* Check whether a task is allowed to perform a xen virtual machine
> > 	    operation. */
> > 	int xen_has_perm(struct task_struct *tsk, u32 perms)
> > 	{
> > 		struct task_security_struct *tsec;
> > 
> > 		tsec = tsk->security;
> > 
> > 		return avc_has_perm(tsec->sid, tsec->sid,
> > 				SECCLASS_XEN, perms, NULL, NULL);
> > 	}
> 
> Doesn't task_has_xen() sound better? ;)
 
 yes?

 yes - i get it :)


 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.

 *clueless*.

 l.




--
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.

Re: xen 2.0 - adding selinux permissions

[Stephen Smalley]

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?

Now, if you want to control interactions among the VMs or access by a VM
to a resource, that is another matter, 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.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton]

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.

Re: xen 2.0 - adding selinux permissions

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Wed, 2004-11-24 at 15:49 +0000, 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.

When would you want a process to be able to control one Xen machine but
not another?


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton]

On Wed, Nov 24, 2004 at 01:13:15PM -0500, Colin Walters wrote:
> On Wed, 2004-11-24 at 15:49 +0000, 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.
> 
> When would you want a process to be able to control one Xen machine but
> not another?
 
 i described such a scenario in an earlier message today to stephen:
 giving an operator-admin the right to reboot a VM running a SQL server
 but NOT giving that same operator the right to reboot the master OS
 which, if you rebooted that, would take down every single VM with it.

 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.

Re: xen 2.0 - adding selinux permissions

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On Wed, 2004-11-24 at 20:19 +0000, Luke Kenneth Casson Leighton wrote:
> On Wed, Nov 24, 2004 at 01:13:15PM -0500, Colin Walters wrote:
> > On Wed, 2004-11-24 at 15:49 +0000, 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.
> > 
> > When would you want a process to be able to control one Xen machine but
> > not another?
>  
>  i described such a scenario in an earlier message today to stephen:
>  giving an operator-admin the right to reboot a VM running a SQL server
>  but NOT giving that same operator the right to reboot the master OS
>  which, if you rebooted that, would take down every single VM with it.

The most flexible approach would be to make the management daemon a
userspace object manager, like dbus and nscd.  Give it a config file
(like the dbus <associate>) which maps VMs to security contexts.  Then
label the /proc/xen interface specifically, and ensure that only the
daemon can interact with it.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: xen 2.0 - adding selinux permissions

[Luke Kenneth Casson Leighton]

On Wed, Nov 24, 2004 at 08:15:46PM -0500, Colin Walters wrote:
> On Wed, 2004-11-24 at 20:19 +0000, Luke Kenneth Casson Leighton wrote:
> > On Wed, Nov 24, 2004 at 01:13:15PM -0500, Colin Walters wrote:
> > > On Wed, 2004-11-24 at 15:49 +0000, 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.
> > > 
> > > When would you want a process to be able to control one Xen machine but
> > > not another?
> >  
> >  i described such a scenario in an earlier message today to stephen:
> >  giving an operator-admin the right to reboot a VM running a SQL server
> >  but NOT giving that same operator the right to reboot the master OS
> >  which, if you rebooted that, would take down every single VM with it.
> 
> The most flexible approach would be to make the management daemon a
> userspace object manager, 

 it's already userspace.

> like dbus and nscd.  Give it a config file
> (like the dbus <associate>) which maps VMs to security contexts.  Then
> label the /proc/xen interface specifically, and ensure that only the
> daemon can interact with it.

 ah.  good idea.


--
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.