From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: severe security issue on dom0/xend/xm/non-root users Date: Mon, 14 Mar 2005 10:44:50 -0600 Message-ID: <4235BF82.8030106@us.ibm.com> References: <20050304195646.GA31213@wavehammer.waldi.eu.org> <422B1E47.9050502@tv.debian.net> <20050313145512.GC29310@tpkurt.garloff.de> <4234B2F5.1070205@blueyonder.co.uk> <20050313215122.GC11358@tpkurt.garloff.de> <20050314145850.GB6037@vienna.egenera.com> <20050314151652.GE11417@tpkurt.garloff.de> <20050314155421.GD6037@vienna.egenera.com> <20050314161316.GM11417@tpkurt.garloff.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <20050314161316.GM11417@tpkurt.garloff.de> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Kurt Garloff Cc: Philip R Auld , David Hopwood , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org 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. Regards, 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. > > >Regards, > > ------------------------------------------------------- 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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click