xm create as root vs xm destroy as normal user

xm create as root vs xm destroy as normal user

[Bob Tanner]

[-- Attachment #1.1: Type: text/plain, Size: 601 bytes --]

Playing around with xen-2.0.6 and I've found something troubling.

I've been creating domU's with 'xm create.' As a simple security check, I did 
a 'xm shutdown' as a normal user. Much to my surprise, that domU shutdown.

Does the default behavior of xen allow a non-root users to shutdown any domU? 
Even domU's that aren't created by the user issuing the 'xm shutdown'?

Thanks.
-- 
Bob Tanner <tanner@real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xm create as root vs xm destroy as normal user

[Kip Macy]

There is currently no notion of capabilities. In 3.0 the default
communication path between xm and xend is now a unix domain socket so
by default only root can execute xm commands.

 -Kip

On 6/24/05, Bob Tanner <tanner@real-time.com> wrote:
> Playing around with xen-2.0.6 and I've found something troubling.
> 
> I've been creating domU's with 'xm create.' As a simple security check, I did
> a 'xm shutdown' as a normal user. Much to my surprise, that domU shutdown.
> 
> Does the default behavior of xen allow a non-root users to shutdown any domU?
> Even domU's that aren't created by the user issuing the 'xm shutdown'?
> 
> Thanks.
> --
> Bob Tanner <tanner@real-time.com>          | Phone : (952)943-8700
> http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
> Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 
>

Re: xm create as root vs xm destroy as normal user

[Bob Tanner]

On Saturday 25 June 2005 06:52 pm, Kip Macy wrote:
> There is currently no notion of capabilities. In 3.0 the default
> communication path between xm and xend is now a unix domain socket so
> by default only root can execute xm commands.

I'm sorry, I do not understand the answer. The "no notion of capabilities", 
does that mean "yes, non-root users can stop Xen sessions in 2.x"?


-- 
Bob Tanner <tanner@real-time.com>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288

Re: xm create as root vs xm destroy as normal user

[Mark Williamson]

> > There is currently no notion of capabilities. In 3.0 the default
> > communication path between xm and xend is now a unix domain socket so
> > by default only root can execute xm commands.
>
> I'm sorry, I do not understand the answer. The "no notion of capabilities",
> does that mean "yes, non-root users can stop Xen sessions in 2.x"?

Yep.  Anyone who can get to Xend's http interface can access all the 
management functions.  The only solution in the 2.0 tree is to allow only 
trusted users the appropriate network access (e.g. no untrusted local users, 
firewall off Xend from non-management networks).

Security in 3.0 will be rather less permissive :-)

Cheers,
Mark

Re: xm create as root vs xm destroy as normal user

[Josh Triplett]

On Mon, 2005-06-27 at 12:42 -0500, Bob Tanner wrote:
> On Saturday 25 June 2005 06:52 pm, Kip Macy wrote:
> > There is currently no notion of capabilities. In 3.0 the default
> > communication path between xm and xend is now a unix domain socket so
> > by default only root can execute xm commands.
> 
> I'm sorry, I do not understand the answer. The "no notion of capabilities", 
> does that mean "yes, non-root users can stop Xen sessions in 2.x"?

It means that there was no security whatsoever on the communication
channel to xend.  AFAIK, anyone who could connect to a local port was
permitted to issue any commands to xend, including stopping a Xen
session.  That is fixed in Xen 3.0 by using a unix domain socket by
default, which can have filesystem permissions set on it.  If you need
some protection in Xen 2.0, you should set up firewall rules to restrict
access to the xend port (and the various domain console ports as well);
iptables can filter on local user/group information, which might be
useful for that purpose.

- Josh Triplett