On Mon, Mar 14, 2005 at 10:54:21AM -0500, Philip R Auld wrote:
> Rumor has it that on Mon, Mar 14, 2005 at 04:16:52PM +0100 Kurt Garloff said:
> > The most straightforward approach would be to have dom0 sysadmin to be
> > the one in control of all the other domains.
>
> That's not really ideal for a virtualized environment. Think of a hosting
> setup for example. You'd really like to have the "hoster" control dom0, but
> have roles that allow a vm sysadmin to control his domain. Console and
> power/reset only perhaps, but still some xend access.
Agreed.
> > Of course, the other domains can have their own root users. This is
> > not changed by restricting control connections to be originating from
> > ports < 1024.
>
> I'm not arguing against that. I was just pointing out the difference in
> roles needed. I think that will actually be orthagonal to protecting
> xend itself. Make it secure first then carefully allow access for roles.
> The tools will need to handle this permission I think.
I agree.
Currently xend just accepts every command that it receives.
Not a good basis to grant role based permissions ...
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,
--
Kurt Garloff <kurt@xxxxxxxxxx> [Koeln, DE]
Physics:Plasma modeling <garloff@xxxxxxxxxxxxxxxxxxx> [TU Eindhoven, NL]
Linux: SUSE Labs (Director) <garloff@xxxxxxx> [Novell Inc]
pgp4SKoMQJQ8U.pgp
Description: PGP signature
|
Home