[libvirt] XML representation of security labels
As part of the sVirt effort, I'm investigating how and when to label the resources accessed by domains. There is already some support for querying security labels in libvirt, although it does not seem to be widely used as yet. For storage pool XML descriptors, there's a permissions element per http://libvirt.org/formatstorage.html : <permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <label>virt_image_t</label> </permissions> The label element in this is currently assumed by libvirt to be an SELinux security label obtainable via getfilecon(3). There are a couple of issues here: 1. We should probably not build security model specific code directly into the library. It's more flexible and also cleaner to abstract the security model out. So, I suggest making a plugin scheme similar to those already present in libvirt, where a security model can register a driver to handle abstracted operations like "getSecurityLabel". 2. The XML format for security labels needs to be extended to indicate which security model is in use, and potentially carry model-specific metadata. For SELinux, we may want to know what type of policy is active, and later, be able to interpret labels generated on other systems. In this case, I suggest we deprecate the existing label element and, if present, assume it's a plain SELinux context (or perhaps ignore it). I'd suggest we implement a new label element to avoid breaking compatibility and to avoid potential confusion with other types of device labels (e.g. as you might see via /dev/disk/by-label). So, how about the following: <seclabel> <model> <!-- model-specific elements in here, to be handled by named security driver, in this case "selinux" --> <selinux> <type>targeted</type> </selinux> </model> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> The model and value elements would be mandatory, but possibly empty. The seclabel element would be a child of the permissions element: <permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <seclabel> <model> <selinux> <type>targeted</type> </selinux> </model> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> </permissions> It would also likely be reused for labeling domains themselves, and other resources. Thoughts? - James -- James Morris <jmorris@namei.org>
On Fri, Aug 29, 2008 at 01:32:27PM +1000, James Morris wrote:
There is already some support for querying security labels in libvirt, although it does not seem to be widely used as yet.
Indeed - I'm not aware of any apps using it yet. It is currently only of marginal benefit, since you can't actually set the label, only see the existing (potentially wrong) label.
For storage pool XML descriptors, there's a permissions element per http://libvirt.org/formatstorage.html :
<permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <label>virt_image_t</label> </permissions>
The label element in this is currently assumed by libvirt to be an SELinux security label obtainable via getfilecon(3).
There are a couple of issues here:
1. We should probably not build security model specific code directly into the library. It's more flexible and also cleaner to abstract the security model out. So, I suggest making a plugin scheme similar to those already present in libvirt, where a security model can register a driver to handle abstracted operations like "getSecurityLabel".
Sounds like a reasonable idea. At very least Solaris won't be using SELinux but their own equivalent.
2. The XML format for security labels needs to be extended to indicate which security model is in use, and potentially carry model-specific metadata. For SELinux, we may want to know what type of policy is active, and later, be able to interpret labels generated on other systems.
In this case, I suggest we deprecate the existing label element and, if present, assume it's a plain SELinux context (or perhaps ignore it).
I'd suggest we implement a new label element to avoid breaking compatibility and to avoid potential confusion with other types of device labels (e.g. as you might see via /dev/disk/by-label).
So, how about the following:
<seclabel>
<model>
<!-- model-specific elements in here, to be handled by named security driver, in this case "selinux" --> <selinux> <type>targeted</type> </selinux>
I'd rather not have security model specific XML element names if practical. We've tried to keep to a naming that is conceptually generic, even if it only has 1 implementation.
</model>
<value>system_u:object_r:virt_image_t:s0</value>
Since the interpretation of the 'value' element's contents depends on the type of security model, I think the type is better designated on the parent 'seclabel' element.
</seclabel>
Would this be sufficient... <seclabel model='selinux'> <policy>targeted</policy> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> I imagine the 'virConnectGetCapabilites()' XML output may well want to specify more detailed metadata about the system's currently active security model & its config. One obvious thing would be the name & version of the policy that is loaded. So if you had a storage volume description indicating seclabel wrt the 'targeted' policy, you could check the host capabilities to ensure the host is actually running the 'targeted' policy and not something else entirely.
The model and value elements would be mandatory, but possibly empty.
The seclabel element would be a child of the permissions element:
<permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <seclabel> <model> <selinux> <type>targeted</type> </selinux> </model> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> </permissions>
It would also likely be reused for labeling domains themselves, and other resources.
Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 29, 2008 at 01:32:27PM +1000, James Morris wrote:
1. We should probably not build security model specific code directly into the library. It's more flexible and also cleaner to abstract the security model out. So, I suggest making a plugin scheme similar to those already present in libvirt, where a security model can register a driver to handle abstracted operations like "getSecurityLabel".
Sounds like a reasonable idea. At very least Solaris won't be using SELinux but their own equivalent.
honnestly I lack expertise to assert the security value, but getting an idea of the kind of API would be nice to review.
2. The XML format for security labels needs to be extended to indicate which security model is in use, and potentially carry model-specific metadata. For SELinux, we may want to know what type of policy is active, and later, be able to interpret labels generated on other systems.
I guess so far we didn't look at the interpretation of security context in the case of migration to a different system. The problem is that except for the base UNIX informations, they are likely to be lost. Still i would expect that storage will have to be shared for such migration, so in the end the case of migration of security context values looks like quite unprobable, but maybe I don't see some of the use cases (heterogenous server pools ?)
In this case, I suggest we deprecate the existing label element and, if present, assume it's a plain SELinux context (or perhaps ignore it).
seems the status quo
I'd suggest we implement a new label element to avoid breaking compatibility and to avoid potential confusion with other types of device labels (e.g. as you might see via /dev/disk/by-label).
So, how about the following:
<seclabel>
<model>
<!-- model-specific elements in here, to be handled by named security driver, in this case "selinux" --> <selinux> <type>targeted</type> </selinux>
I'd rather not have security model specific XML element names if practical. We've tried to keep to a naming that is conceptually generic, even if it only has 1 implementation.
right in general we have been using element names for specifying the concepts and attributes values to explain the specifics.
</model>
<value>system_u:object_r:virt_image_t:s0</value>
Since the interpretation of the 'value' element's contents depends on the type of security model, I think the type is better designated on the parent 'seclabel' element.
</seclabel>
Would this be sufficient...
<seclabel model='selinux'> <policy>targeted</policy> <value>system_u:object_r:virt_image_t:s0</value> </seclabel>
that looks more homogeneous. i don't know hos that would map to other security models, examples would be great
I imagine the 'virConnectGetCapabilites()' XML output may well want to specify more detailed metadata about the system's currently active security model & its config. One obvious thing would be the name & version of the policy that is loaded. So if you had a storage volume description indicating seclabel wrt the 'targeted' policy, you could check the host capabilities to ensure the host is actually running the 'targeted' policy and not something else entirely.
good point, that would be needed by the management tools Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Fri, 29 Aug 2008, Daniel Veillard wrote:
2. The XML format for security labels needs to be extended to indicate which security model is in use, and potentially carry model-specific metadata. For SELinux, we may want to know what type of policy is active, and later, be able to interpret labels generated on other systems.
I guess so far we didn't look at the interpretation of security context in the case of migration to a different system. The problem is that except for the base UNIX informations, they are likely to be lost. Still i would expect that storage will have to be shared for such migration, so in the end the case of migration of security context values looks like quite unprobable, but maybe I don't see some of the use cases (heterogenous server pools ?)
In the simplest case, we'll just be wanting to ensure that domains are running with distinct labels for separation purposes, so that concept may be possible to convey during migration. As for specific labels (e.g. "privileged", "company-confidential" etc.), this is a general problem to be solved for distributed MAC security, and we would not expect to solve it here in the first iteration. There's a term used in this area called Domain of Interpretation (DOI), which is essentially label metatdata used to interpret/translated labels between systems. It's something that can be added to the XML if/when needed, but we don't need it now. The Labeled NFS and labeled networking projects are addressing similar issues, and it's possible that one or both would be involved in distributing sVirt across the network.
<seclabel model='selinux'> <policy>targeted</policy> <value>system_u:object_r:virt_image_t:s0</value> </seclabel>
that looks more homogeneous. i don't know hos that would map to other security models, examples would be great
I've cc'd Casey, who wrote Smack. I'm not sure what the application of Smack would be here (and Casey may not like the idea at all), but it is a label-based MAC system. (The thread starts here: https://www.redhat.com/archives/libvir-list/2008-August/msg00740.html) - James -- James Morris <jmorris@namei.org>
On Fri, Aug 29, 2008 at 05:13:23PM +1000, James Morris wrote:
In the simplest case, we'll just be wanting to ensure that domains are running with distinct labels for separation purposes, so that concept may be possible to convey during migration.
As for specific labels (e.g. "privileged", "company-confidential" etc.), this is a general problem to be solved for distributed MAC security, and we would not expect to solve it here in the first iteration. There's a term used in this area called Domain of Interpretation (DOI), which is essentially label metatdata used to interpret/translated labels between systems. It's something that can be added to the XML if/when needed, but we don't need it now.
Can I add that there's a very specific use case that I've been asked about several times. I think it's worth bearing it in mind. The "ISP scenario" ------------------ An ISP is running a hosting facility where they supply Xen guests to customers. Each physical host runs many guests, and clearly to maximize revenue guests belonging to many different customers may be running on the same single host. The host is running RHEL, with a management interface offered through libvirtd. The ISP wants to offer customers a facility where they can connect to the host libvirtd and manage any guests that they own. They must be able to monitor, start, stop, etc. their own guests. However they must not be able to interfere with guests owned by other customers. (It's an open question whether they can even *see* guests owned by other customers -- I'm guessing that most ISPs would wish to prevent this as well). - - - Whatever we do should allow the ISP scenario. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
James Morris wrote:
On Fri, 29 Aug 2008, Daniel Veillard wrote:
2. The XML format for security labels needs to be extended to indicate which security model is in use, and potentially carry model-specific metadata. For SELinux, we may want to know what type of policy is active, and later, be able to interpret labels generated on other systems.
I guess so far we didn't look at the interpretation of security context in the case of migration to a different system. The problem is that except for the base UNIX informations, they are likely to be lost. Still i would expect that storage will have to be shared for such migration, so in the end the case of migration of security context values looks like quite unprobable, but maybe I don't see some of the use cases (heterogenous server pools ?)
In the simplest case, we'll just be wanting to ensure that domains are running with distinct labels for separation purposes, so that concept may be possible to convey during migration.
As for specific labels (e.g. "privileged", "company-confidential" etc.), this is a general problem to be solved for distributed MAC security, and we would not expect to solve it here in the first iteration. There's a term used in this area called Domain of Interpretation (DOI), which is essentially label metatdata used to interpret/translated labels between systems. It's something that can be added to the XML if/when needed, but we don't need it now.
The Labeled NFS and labeled networking projects are addressing similar issues, and it's possible that one or both would be involved in distributing sVirt across the network.
<seclabel model='selinux'> <policy>targeted</policy> <value>system_u:object_r:virt_image_t:s0</value> </seclabel>
that looks more homogeneous. i don't know hos that would map to other security models, examples would be great
I've cc'd Casey, who wrote Smack. I'm not sure what the application of Smack would be here (and Casey may not like the idea at all), but it is a label-based MAC system.
<seclabel model='Smack'> <value>_</value> </seclabel> Seems like a lot of mechanism to pass a string, but this is the 21st century.
(The thread starts here: https://www.redhat.com/archives/libvir-list/2008-August/msg00740.html)
- James
On Fri, Aug 29, 2008 at 08:46:35AM +0200, Daniel Veillard wrote:
On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote:
On Fri, Aug 29, 2008 at 01:32:27PM +1000, James Morris wrote:
I'd suggest we implement a new label element to avoid breaking compatibility and to avoid potential confusion with other types of device labels (e.g. as you might see via /dev/disk/by-label).
So, how about the following:
<seclabel>
<model>
<!-- model-specific elements in here, to be handled by named security driver, in this case "selinux" --> <selinux> <type>targeted</type> </selinux>
I'd rather not have security model specific XML element names if practical. We've tried to keep to a naming that is conceptually generic, even if it only has 1 implementation.
right in general we have been using element names for specifying the concepts and attributes values to explain the specifics.
</model>
<value>system_u:object_r:virt_image_t:s0</value>
Since the interpretation of the 'value' element's contents depends on the type of security model, I think the type is better designated on the parent 'seclabel' element.
</seclabel>
Would this be sufficient...
<seclabel model='selinux'> <policy>targeted</policy> <value>system_u:object_r:virt_image_t:s0</value> </seclabel>
that looks more homogeneous. i don't know hos that would map to other security models, examples would be great
I've just had a read of the Xen user guide on their ACM security module http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user.pdf It kicks off around page 55 In that example a domain is labeled along the lines of 'ACM:mytest:A-Bank' where 'ACM' is the security model, 'mytest' is the policy name, and 'A-Bank' is the seclabel value. Disk files have the same breakdown. This would map quite easily to <seclabel model='acm'> <policy>mytest</policy> <value>A-Bank</value> </seclabel> Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote:
Indeed - I'm not aware of any apps using it yet. It is currently only of marginal benefit, since you can't actually set the label, only see the existing (potentially wrong) label.
It always seemed to me a bit worrying that libvirtd would actually set labels on things. James, am I wrong to be worrying about this? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
On Fri, Aug 29, 2008 at 01:41:09PM +0100, Richard W.M. Jones wrote:
On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote:
Indeed - I'm not aware of any apps using it yet. It is currently only of marginal benefit, since you can't actually set the label, only see the existing (potentially wrong) label.
It always seemed to me a bit worrying that libvirtd would actually set labels on things. James, am I wrong to be worrying about this?
It depends on the threats you are attempting to protect against. For the sVirt work we're primarily interested in protecting the network & host from guests, and guests from each other. libvirtd is the control plane, so it has no choice but to deal with labelling If on the other hand we were trying to protect against flaws in libvirtd itself, then this wouldn't be a viable approach. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Richard W.M. Jones wrote:
On Fri, Aug 29, 2008 at 06:00:36AM +0100, Daniel P. Berrange wrote:
Indeed - I'm not aware of any apps using it yet. It is currently only of marginal benefit, since you can't actually set the label, only see the existing (potentially wrong) label.
It always seemed to me a bit worrying that libvirtd would actually set labels on things. James, am I wrong to be worrying about this?
Rich.
We can also control the labeles that libvitd can put on objects. So it will not be able to put random labels on files. Only labels that it owns. As an example udev can label all devices with device labels, but it is not allowed to label random files as shadow_t.
participants (6)
-
Casey Schaufler -
Daniel J Walsh -
Daniel P. Berrange -
Daniel Veillard -
James Morris -
Richard W.M. Jones