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] severe security issue on dom0/xend/xm/non-root users

To: Kurt Garloff <kurt@xxxxxxxxxx>
Subject: Re: [Xen-devel] severe security issue on dom0/xend/xm/non-root users
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Mon, 14 Mar 2005 10:44:50 -0600
Cc: Philip R Auld <pauld@xxxxxxxxxxx>, David Hopwood <david.hopwood@xxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 14 Mar 2005 16:46:37 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050314161316.GM11417@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: IBM
References: <20050304195646.GA31213@xxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.61.0503051651070.31720@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <422B1E47.9050502@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503061613160.31720@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050313145512.GC29310@xxxxxxxxxxxxxxxxx> <4234B2F5.1070205@xxxxxxxxxxxxxxxx> <20050313215122.GC11358@xxxxxxxxxxxxxxxxx> <20050314145850.GB6037@xxxxxxxxxxxxxxxxxx> <20050314151652.GE11417@xxxxxxxxxxxxxxxxx> <20050314155421.GD6037@xxxxxxxxxxxxxxxxxx> <20050314161316.GM11417@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Kurt Garloff wrote:

I agree.

Currently xend just accepts every command that it receives.
Not a good basis to grant role based permissions ...
One approach to role based permissions is to have dom0 enforce policies. Another approach is to enforce policies at the hypervisor level which is what sHype does.

One problem with any sort of Xend-level policies is managing authentication in a large network. Especially if you start dealing with certificates (you've got to tie Xend into a larger certificate distribution system).

I think relying on local authentication is a useful approach. Policies can be enforced at group/user granularities and you get every pam/nss based sign-on solution for free.

You're restricted by the Unix user model (small groups, no nested groups, etc.) but you gain an awful lot of additional functionality.

Anthony Liguori

So, we need to have some restrictions first, so tools can
grant them for the right people.

And my suggestion was binding to localhost only and requiring a port < 1024 -- then you'd need to be a local user with CAP_NET_BIND_SERVICE capability. Granting additional rights by providing this capability from a setuid root wrapper (or a PAM service that sets this on login)
should not be too hard and straightforward enough to not introduce
another load of security holes.

The disadvantage of this is that it's a all or nothing approach.
xend could be made more clever and require the user to show
different certificates for different operations on different
domains. But this is no short term solution.

It would give a rather large matrix of certificates, one dimension
being the kind of operation (list, restart, sysrq, balloon, scheduler,
save/restrore, migrate, ...), another one being the domain. We could
have master certificates for both directions, of course.


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.
Xen-devel mailing list

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