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

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.


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.


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

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