10:32 p.m.
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(a)namei.org>
midnight
New subject: [libvirt] Re: XML representation of security labels
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 :|
1:46 a.m.
New subject: [libvirt] Re: XML representation of security labels
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
2:13 a.m.
New subject: [libvirt] Re: XML representation of security labels
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(a)namei.org>
7:48 a.m.
New subject: [libvirt] Re: XML representation of security labels
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
10:07 a.m.
New subject: [libvirt] Re: XML representation of security labels
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
2:29 a.m.
New subject: [libvirt] Re: XML representation of security labels
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 :|
7:41 a.m.
New subject: [libvirt] Re: XML representation of security labels
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/
7:53 a.m.
New subject: [libvirt] Re: XML representation of security labels
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 :|
8:21 a.m.
New subject: [libvirt] Re: XML representation of security labels
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.
5930
days inactive
5930
days old
9 comments
6 participants
participants (6)
-
Casey Schaufler -
Daniel J Walsh -
Daniel P. Berrange -
Daniel Veillard -
James Morris -
Richard W.M. Jones