This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] protecting xen startup

On Tue, Nov 23, 2004 at 10:49:24PM +0000, Mark Williamson wrote:
> >is there anything preventing that interface from being removed, such
> >that the client/server bit is munged into a single application?
> In older releases, there wasn't a Xend.  Instead we had a set of 
> management scripts that called various operations directly.  You could in 
> principle munge xm and xend together into a big megatool but it wouldn't 
> be pretty.

 i'll take that as a challenge, then :)

> Xend makes concurrency control much easier, provides a central point of 
> contact regarding machine state and demuxes the virtual consoles of the 
> domain.  You'd have to address these problems in addition to combining the 
> tools, which would take a fair bit of hacking to do properly.


 assuming that 1) i don't want a central point of contact i only want
 _one_ point of contact and 2) i can live without virtual consoles
 until i understand the code enough and can get away with
 using ssh logins instead:

 would this be a simple enough task for someone not entirely
 familiar with xen's code [but who has developed a number of
 20k+ line python projects over the past four years]?

> >>Not exactly.  At the Linux Level, there aren't any extra Xen system calls.
> >>Most commands are issued to Xen by performing ioctls on the
> >>/proc/xen/privcmd file.
> >
> >
> >that means that it will be possible to lock down at the very least the
> >access to /proc/xen and later, should it prove worthwhile, to protect
> >each ioctl with a new selinux security id per ioctl command.
> Right now, only root (actually, probably users with the CAP_SYSADMIN 
> capability or similar) can do operations on /proc/xen.  

 [which, please excuse me for saying so, doesn't exactly help if that
 root-only interface is then exposed via an open high port number!! :) ]

> Also, many Xen 
> operations are mapped onto one ioctl call so as it is you can't do very 
> fine grained protection based on ioctl number.  

 i was thinking of adding in an LSM hook function that received the
 ioctl number as one of its arguments, translated that in a case
 statement into the corresponding selinux SIDs, and from there checked
 an selinux permission - in a similar way that security/selinux/hooks.c's
 selinux_file_ioctl() or the selinux_file_fcntl() function operates.

 i.e. not using file_has_perm() but task_has_perm() instead.

 then the first thing that the xen ioctl function does is call that LSM
 hook function.

 it would therefore also be possible for someone else to write a
 corresponding LSM linux capabilities function call, too.  should
 someone so wish.


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

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>