8:56 a.m.
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:
int
virDomainSuspend(virDomainPtr domain)
{
virConnectPtr conn;
DEBUG("domain=%p", domain);
if (!VIR_IS_CONNECTED_DOMAIN(domain)) {
virLibDomainError(NULL, VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
return (-1);
}
- if (domain->conn->flags & VIR_CONNECT_RO) {
- virLibDomainError(domain, VIR_ERR_OPERATION_DENIED, __FUNCTION__);
- return (-1);
- }
+ if (!check_permission (domain, OP_SUSPEND)) return -1;
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.
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.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
10 a.m.
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.
Hum, that still sounds very specific to me, it's just one special case
that we need to keep in mind when designing the general solution.
(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.
Understood
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:
int
virDomainSuspend(virDomainPtr domain)
{
virConnectPtr conn;
DEBUG("domain=%p", domain);
if (!VIR_IS_CONNECTED_DOMAIN(domain)) {
virLibDomainError(NULL, VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
return (-1);
}
- if (domain->conn->flags & VIR_CONNECT_RO) {
- virLibDomainError(domain, VIR_ERR_OPERATION_DENIED, __FUNCTION__);
- return (-1);
- }
+ if (!check_permission (domain, OP_SUSPEND)) return -1;
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.
Yes that to me is uncontroversial, we need to plug finer grained auth
at each call level and not just at Connect time (though I still think having
a specific ConnectReadOnly method makes sense), now the big question is
how do we actually plug the policy checks in (and also what).
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.
I looked at the SASL patches, the checking there seems to be done
in the remote code front-end (assuming I understood this correctly)
rather than in the top level entry point (which are presumably only
called on the client side. Still it makes sense to be able to do
finer access control locally (or on the client side) that doesn't
prevent the approach needed by the SASL patch.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
1 p.m.
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@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 -=|
6212
days inactive
6212
days old
2 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones