RE: [Xen-devel] protecting xen startup

["Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mark Williamson
> Sent: 23 November 2004 22:49
> To: Luke Kenneth Casson Leighton
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: 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.

Well not quite since in the older releases we also didn't have event
channels and control channels.

Basically with the new IO model we need something somewhere which either
connects event channels or which at least assists two domains to set up
a event channel with shared memory pages (ie a name server).

>From a security point of view we probably should/need to restructure the
current xend significantly into at least two components: a small name
server and a daemon/tool which knows about assignment of higher level
devices to domains etc. Note that this will also require changes to
backend and frontends etc, ie, it's non-trivial.

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

In general, as ian pointed out, the current design is more geared
towards clusters, however, we started looking into security applications
of Xen and will hopefully address these issues in future releases.
Currently, our thinking is also very much along the lines of leveraging
SELinux as much as possible at least for the first prototype, however
there are several changes we would have to make first ...

rolf

> 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


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