[Libvir] [Suggestion] The "ISP scenario"

[Daniel P. Berrange]

On Mon, Nov 19, 2007 at 02:56:10PM +0000, Richard W.M. Jones wrote:
> This pattern has come up a few times now:
> 
> ISP provides a Xen hosting service to customers.  ISP wants to provide 
> some basic statistics to their customers.  The statistics could be 
> provided to a customer through the libvirt remote protocol, eg:
> 
>   customer$ virsh -c xen://dom0/ dominfo mydom
> 
> But the problem with this is that (as libvirt is currently architected) 
> _any_ access to dom0, if it authenticates, gives access to information 
> from all domains.
> 
> We've previously discussed adding access control using something like 
> SELinux (see for example: 
> https://www.redhat.com/archives/libvir-list/2007-August/msg00030.html) 
> but nothing much has come of it so far.
> 
> But can we solve the single common case above directly, without 
> thwarting our ability to solve the bigger picture later?
> 
> My suggestion is that we add an option to /etc/libvirt/libvirtd.conf, 
> something like:
> 
>   tls_restrict_dn: [
>     "DN1", "name:customer1",
>     "DN2", "uuid:12345678",
>     "DN3", "*"
>   ]
> 
> with the meaning that (presumably a customer) connecting with 
> certificate DN1 could only find out information about the domain 
> "customer1", DN2 similarly, DN3 is a privileged client, and any other DN 
> would be rejected.
> 
> (Compare and contrast to tls_allowed_dn_list: 
> http://libvirt.org/remote.html#Remote_libvirtd_configuration)
> 
> An implementation of this would modify the call to virConnectOpen to add 
> an additional flag (or call?) allowing the access control to be passed, 
> and this would have to be checked in the relevant virDomain* calls.
> 
> This is not dissimilar to how read-only connections are implemented in 
> libvirtd currently.
> 
> I would also suggest as a matter of course that we modify all public API 
> calls in src/libvirt.c to add a call to a generic permission checking 
> routine, for example:

Yep, this example as you show sounds like a good idea regardless. Basically
any API call will have a triple of a (object, subject, operation) to be 
checked. In the latest update of the SASL patches which I've not yet posted
there is a a subject associated with all remote connections. This is basically
the SASL authenticated username, either 'dan', or 'dan at REALM' depending on
the particular auth scheme used. 

> With the initial implementation of check_permission just doing the 
> VIR_CONNECT_RO check to start with, but able to do other checks in future.

Seems reasonable. Depending on how PolicyKit develops in the future, it
may well be possible for us to turn 'check_permission' into a simple
policykit call. Or we may end up taking to some API which does an SELinux
check, or something ele. It'll be good to have this all isolated in one
place now.

> Also relevant to this is SASL support, see: 
> https://www.redhat.com/archives/libvir-list/2007-November/msg00005.html 
> since AIUI this changes the possible formats for Distinguished Names, or 
> could even make DNs irrelevant.

The code I've got can run SASL over both plain & TLS connections, so we 
could conceivably have both a DN from the cert, and a SASL username. It
shouldn't really matter for our internal APIs though - its just an opaque
string representing the subject. If we have SASL username, use that, otherwise
just fallback to the Cert DN.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|