| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
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
|
|
|
| |
|
Home