Re: [Xen-devel] protecting xen startup

[Mark Williamson <maw48@xxxxxxxxxxxxxxxx>]

> 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.
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.
> > 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.
> GREAT.
>
> 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.  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.  What you describe would be 
technically possible if a separate ioctl was allocated for each operation, 
though.
Cheers,
Mark


-------------------------------------------------------
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. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel