SELinux mixed/virtualisation policy

SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

As this is my first message to the list, I'd like to introduce myself.
I'm a Security Engineer at IBM Linux Technology Center, Founder at RISE
Security, and I'm currently working on Common Criteria Evaluation.

During the work on developing test cases for KVM and libvirt using the
MLS policy, after several failed attempts to make KVM and libvirt work
using MLS policy out of the box, I've been informed that libvirt does
not support dynamic labeling using MLS policy, which actually makes sense.

However, I and Dan Walsh (who kindly informed me about libvirt) both
agree that dynamic labeling is more secure than manual labeling using
MLS policy, for virtual machine environments.

This made me think for several hours about the policies currently
available and the virtualised environments. Thus, I'd like to make a
proposal and hear your opinions.


SELinux mixed policy

The SELinux mixed policy can have non hierarchical sensitivities that
have the same behavior of a categorized only environment. Such
sensitivities should not be included in the default sensitivity
hierarchy (i.e. s0 to s15). Thus, all rules for these sensitivities
should be explicitly stated. This allows creating a unique sensitivity
for virtual machine environments that is not part of the default
sensitivity hierarchy.

One of the main goals of virtualisation (amongst others) is the
representation of a physical environment in a logical environment to
obtain better usage of the available resources. However, physical and
logical objects should not belong to the same hierarchy, as it is in a
non virtualised environment.

In a non virtualised environment, one physical computer can not dominate
and/or communicate with a process of another physical computer without
any sort of well defined communication protocol, which can not infer a
hierarchy between physical objects and logical objects. Thus, a physical
computer can not dominate a process of another physical computer (i.e. a
guest -a process representing a virtual machine- should never dominate a
process of the host), something that is actually possible in the
currently available policies.

The main goal of having non hierarchical sensitivities available, or, at
a minimum, a sensitivity optionally available for use by the virtual
environment (i.e. sv -which does not belongs to the default hierarchy-),
is to better represent a physical environment where a physical computer
(usually) can not be automatically subjected to another physical
computer that has been compromised.


Virtualisation policy

Considering the above policy, a police could be refined to allow a
hierarchy to be defined between the guests only (i.e. sv0 to sv15), and
rules between the host sensitivities and guest sensitivities should be
explicitly stated. The categories constrains for the virtualisation
sensitivities should behave the same way as the constrains for the
standard sensitivities. This will result in the following

Host processes (in a non virtualised environment, a process)
s0-s15:c0-c255

Host processes representing virtual machines (in a non virtualised
environment, a physical computer)
sv0-sv15:c0-c255

The communication between them should be explicitly stated, as they are
two different types of object in a non virtualised environment (and the
communication between them only would occur when explicitly stated).

Please, let me know what you think. Any comments, critics and/or
suggestions would be greatly appreciated.

Best regards,

- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2h5Q8ACgkQkcIYeh81wLmeoACgkabADsP+i80M3VxFMw1deXk/
V4QAn2AbkKdzlSH7xM4xLj06ftAimm5n
=egxz
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Stephen Smalley]

On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
> However, I and Dan Walsh (who kindly informed me about libvirt) both
> agree that dynamic labeling is more secure than manual labeling using
> MLS policy, for virtual machine environments.

Can you elaborate on what your concern is there?  If it is merely that
two VMs at the same level are not isolated via the MLS policy, then that
isn't a MLS concern, and you could use TE instead to isolate the VMs of
the same level.

> SELinux mixed policy
> 
> The SELinux mixed policy can have non hierarchical sensitivities that
> have the same behavior of a categorized only environment. Such
> sensitivities should not be included in the default sensitivity
> hierarchy (i.e. s0 to s15). Thus, all rules for these sensitivities
> should be explicitly stated. This allows creating a unique sensitivity
> for virtual machine environments that is not part of the default
> sensitivity hierarchy.

If I understand you correctly, this would require a fundamental change
to the kernel security server and to the policy toolchain.  You would be
changing the SELinux security model, not just tuning the configuration.

> In a non virtualised environment, one physical computer can not dominate
> and/or communicate with a process of another physical computer without
> any sort of well defined communication protocol, which can not infer a
> hierarchy between physical objects and logical objects. Thus, a physical
> computer can not dominate a process of another physical computer (i.e. a
> guest -a process representing a virtual machine- should never dominate a
> process of the host), something that is actually possible in the
> currently available policies.

Technically you can ensure that the qemu processes on the host are
"incomparable" to other host processes either by:
1) Using distinct types in the TE policy so that only very limited
interactions are possible (this is already the case with libvirt/KVM as
I understand it), or
2) Dedicating one category to all host processes and another category to
all qemu processes such that they are always incomparable in the MLS
policy.

That doesn't require a change to the SELinux model, the policy
toolchain, or the kernel security server.

> The main goal of having non hierarchical sensitivities available, or, at
> a minimum, a sensitivity optionally available for use by the virtual
> environment (i.e. sv -which does not belongs to the default hierarchy-),
> is to better represent a physical environment where a physical computer
> (usually) can not be automatically subjected to another physical
> computer that has been compromised.

But in the virtualized environment, a compromise of the qemu process can
in fact lead to compromise of other qemu processes or the host.  And the
security context is for the qemu process, not for the "virtual machine"
per se, where the qemu process is in fact a host OS
subject/abstraction.  

> Host processes (in a non virtualised environment, a process)
> s0-s15:c0-c255
> 
> Host processes representing virtual machines (in a non virtualised
> environment, a physical computer)
> sv0-sv15:c0-c255

If you want to guarantee incomparable labels in the MLS policy, then I
think you can achieve that through clever use of categories, as
described above.  But I think it is simpler to achieve it through the
use of TE types, and largely already done for you.

> The communication between them should be explicitly stated, as they are
> two different types of object in a non virtualised environment (and the
> communication between them only would occur when explicitly stated).

That's largely already the case via the TE policy unless I misunderstand
you.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Russell Coker]

On Mon, 11 Apr 2011, Ramon de Carvalho Valle <rcvalle@linux.vnet.ibm.com> 
wrote:
> The SELinux mixed policy can have non hierarchical sensitivities that
> have the same behavior of a categorized only environment. Such
> sensitivities should not be included in the default sensitivity
> hierarchy (i.e. s0 to s15). Thus, all rules for these sensitivities
> should be explicitly stated. This allows creating a unique sensitivity
> for virtual machine environments that is not part of the default
> sensitivity hierarchy.

One way of doing this is for the sysadmin to assign categories c0.c511 to non-
VM levels and categories c512.c1023 to virtual machines - or any other 
partitioning scheme that you might imagine.  Another possibility is to have 
one category assigned to the sensitivity label for all virtual machines and 
another assigned to the sensitivity label for all contexts that aren't used 
for VMs.  If you have two sensitivity labels that are incomparable then no 
data flows between them.

One of the many ways of using categories would be to assign a discrete pair of 
categories to each thing you want to restrict.  One possibility I idly 
considered some time ago was to use MMCS labels for a build server.  Every 
package that would be built would be assigned a pair of categories as part of 
the sensitivity label, with the default policy build of 1024 categories that 
permits about half a million combinations which is more than enough to build 
the ~15,000 Debian packages with a different context for each one.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/2011 09:40 AM, Stephen Smalley wrote:
> On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
>> However, I and Dan Walsh (who kindly informed me about libvirt) both
>> agree that dynamic labeling is more secure than manual labeling using
>> MLS policy, for virtual machine environments.
> 
> Can you elaborate on what your concern is there?  If it is merely that
> two VMs at the same level are not isolated via the MLS policy, then that
> isn't a MLS concern, and you could use TE instead to isolate the VMs of
> the same level.
> 
I think what he is after is the convenience of dynamic labeling, for
isolation.  Yes he could create new types for each instance, which every
virtual machine would need, this could cause a potential explosion in
the number of types and would be subject to failure.  It would be
putting a large onus on the Admin to manage all of these types.  The
real beauty of dynamic labeling is that it just works.

>> SELinux mixed policy
>>
>> The SELinux mixed policy can have non hierarchical sensitivities that
>> have the same behavior of a categorized only environment. Such
>> sensitivities should not be included in the default sensitivity
>> hierarchy (i.e. s0 to s15). Thus, all rules for these sensitivities
>> should be explicitly stated. This allows creating a unique sensitivity
>> for virtual machine environments that is not part of the default
>> sensitivity hierarchy.
> 
> If I understand you correctly, this would require a fundamental change
> to the kernel security server and to the policy toolchain.  You would be
> changing the SELinux security model, not just tuning the configuration.
> 
>> In a non virtualised environment, one physical computer can not dominate
>> and/or communicate with a process of another physical computer without
>> any sort of well defined communication protocol, which can not infer a
>> hierarchy between physical objects and logical objects. Thus, a physical
>> computer can not dominate a process of another physical computer (i.e. a
>> guest -a process representing a virtual machine- should never dominate a
>> process of the host), something that is actually possible in the
>> currently available policies.
> 
> Technically you can ensure that the qemu processes on the host are
> "incomparable" to other host processes either by:
> 1) Using distinct types in the TE policy so that only very limited
> interactions are possible (this is already the case with libvirt/KVM as
> I understand it), or
> 2) Dedicating one category to all host processes and another category to
> all qemu processes such that they are always incomparable in the MLS
> policy.
> 
> That doesn't require a change to the SELinux model, the policy
> toolchain, or the kernel security server.
> 
>> The main goal of having non hierarchical sensitivities available, or, at
>> a minimum, a sensitivity optionally available for use by the virtual
>> environment (i.e. sv -which does not belongs to the default hierarchy-),
>> is to better represent a physical environment where a physical computer
>> (usually) can not be automatically subjected to another physical
>> computer that has been compromised.
> 
> But in the virtualized environment, a compromise of the qemu process can
> in fact lead to compromise of other qemu processes or the host.  And the
> security context is for the qemu process, not for the "virtual machine"
> per se, where the qemu process is in fact a host OS
> subject/abstraction.  
> 
>> Host processes (in a non virtualised environment, a process)
>> s0-s15:c0-c255
>>
>> Host processes representing virtual machines (in a non virtualised
>> environment, a physical computer)
>> sv0-sv15:c0-c255
> 
> If you want to guarantee incomparable labels in the MLS policy, then I
> think you can achieve that through clever use of categories, as
> described above.  But I think it is simpler to achieve it through the
> use of TE types, and largely already done for you.
> 
>> The communication between them should be explicitly stated, as they are
>> two different types of object in a non virtualised environment (and the
>> communication between them only would occur when explicitly stated).
> 
> That's largely already the case via the TE policy unless I misunderstand
> you.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2jHS0ACgkQrlYvE4MpobMohACfRBhDNBhnMFTh2v96/eltem/z
5B8AoLNXyNWuuILviOy7nxQkNDGpb5sN
=jY+I
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Stephen Smalley]

On Mon, 2011-04-11 at 11:24 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/11/2011 09:40 AM, Stephen Smalley wrote:
> > On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
> >> However, I and Dan Walsh (who kindly informed me about libvirt) both
> >> agree that dynamic labeling is more secure than manual labeling using
> >> MLS policy, for virtual machine environments.
> > 
> > Can you elaborate on what your concern is there?  If it is merely that
> > two VMs at the same level are not isolated via the MLS policy, then that
> > isn't a MLS concern, and you could use TE instead to isolate the VMs of
> > the same level.
> > 
> I think what he is after is the convenience of dynamic labeling, for
> isolation.  Yes he could create new types for each instance, which every
> virtual machine would need, this could cause a potential explosion in
> the number of types and would be subject to failure.  It would be
> putting a large onus on the Admin to manage all of these types.  The
> real beauty of dynamic labeling is that it just works.

The types could be automatically generated from a template, and managed
by libvirt in much the same way it presently manages categories.

In any event, he can do the same thing by use of categories rather than
introducing an incomparable set of sensitivities, and that wouldn't
require any changes to the policy toolchain or kernel security server.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/2011 01:33 PM, Stephen Smalley wrote:
> On Mon, 2011-04-11 at 11:24 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/11/2011 09:40 AM, Stephen Smalley wrote:
>>> On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
>>>> However, I and Dan Walsh (who kindly informed me about libvirt) both
>>>> agree that dynamic labeling is more secure than manual labeling using
>>>> MLS policy, for virtual machine environments.
>>>
>>> Can you elaborate on what your concern is there?  If it is merely that
>>> two VMs at the same level are not isolated via the MLS policy, then that
>>> isn't a MLS concern, and you could use TE instead to isolate the VMs of
>>> the same level.
>>>
>> I think what he is after is the convenience of dynamic labeling, for
>> isolation.  Yes he could create new types for each instance, which every
>> virtual machine would need, this could cause a potential explosion in
>> the number of types and would be subject to failure.  It would be
>> putting a large onus on the Admin to manage all of these types.  The
>> real beauty of dynamic labeling is that it just works.
Yes, exactly.

> 
> The types could be automatically generated from a template, and managed
> by libvirt in much the same way it presently manages categories.
> 
> In any event, he can do the same thing by use of categories rather than
> introducing an incomparable set of sensitivities, and that wouldn't
> require any changes to the policy toolchain or kernel security server.
> 
I know it may be too intrusive to the policy toolchain. However,  there
are a number of benefits that may be taken in consideration.

This allows the categorization of processes representing virtual machine
environments in different sensitivities within a pre-defined standard
set which belongs only this type of processes-Instead of manually
reserving a non standard range of categories. Also, this may allow
virtualisation software to act in a well defined environment instead of
each one adopting custom different solutions (i.e. non standard range of
categories, dynamic labeling, different types for each instance).

Also, as Daniel said, this may allow the use of dynamic labeling within
one of these sensitivities (i.e. sv0), and allow custom processes
representing virtual machine environments to have static labels in the
same or other sensitivities with higher privileges. No other types of
processes should have access to these sensitivities unless explicitly
stated, which may be the case of libvirt.

This can be an entirely optional feature aimed to virtualised
environments and opens the possibility for developing new features that
could benefit from this additional level of granularity.

- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2jNxIACgkQkcIYeh81wLk/cACfefbk0X60e5e4NOWC3yQrygV8
/28An3xokMo4uCQ6lxZqlV1NhzuP2+NB
=qsVc
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/2011 11:20 AM, Russell Coker wrote:
> On Mon, 11 Apr 2011, Ramon de Carvalho Valle <rcvalle@linux.vnet.ibm.com> 
> wrote:
>> The SELinux mixed policy can have non hierarchical sensitivities that
>> have the same behavior of a categorized only environment. Such
>> sensitivities should not be included in the default sensitivity
>> hierarchy (i.e. s0 to s15). Thus, all rules for these sensitivities
>> should be explicitly stated. This allows creating a unique sensitivity
>> for virtual machine environments that is not part of the default
>> sensitivity hierarchy.
> 
> One way of doing this is for the sysadmin to assign categories c0.c511 to non-
> VM levels and categories c512.c1023 to virtual machines - or any other 
> partitioning scheme that you might imagine.  Another possibility is to have 
> one category assigned to the sensitivity label for all virtual machines and 
> another assigned to the sensitivity label for all contexts that aren't used 
> for VMs.  If you have two sensitivity labels that are incomparable then no 
> data flows between them.
Yes, I agree. However, what I am looking for is a standardization of
what should be implemented in this type of situation, with an additional
level of granularity.

> 
> One of the many ways of using categories would be to assign a discrete pair of 
> categories to each thing you want to restrict.  One possibility I idly 
> considered some time ago was to use MMCS labels for a build server.  Every 
> package that would be built would be assigned a pair of categories as part of 
> the sensitivity label, with the default policy build of 1024 categories that 
> permits about half a million combinations which is more than enough to build 
> the ~15,000 Debian packages with a different context for each one.
Actually, this is what libvirt does with dynamic labeling enabled.
However, it currently does not work with MLS policy.

> 

- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2jObgACgkQkcIYeh81wLm++wCbBZsh2w7fT8ZwNcYfpxyAa0vh
BysAnRi6U9mNGYShaqQ4uj2PhhcpFb4e
=W/Vj
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/2011 12:33 PM, Stephen Smalley wrote:
> On Mon, 2011-04-11 at 11:24 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/11/2011 09:40 AM, Stephen Smalley wrote:
>>> On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
>>>> However, I and Dan Walsh (who kindly informed me about libvirt) both
>>>> agree that dynamic labeling is more secure than manual labeling using
>>>> MLS policy, for virtual machine environments.
>>>
>>> Can you elaborate on what your concern is there?  If it is merely that
>>> two VMs at the same level are not isolated via the MLS policy, then that
>>> isn't a MLS concern, and you could use TE instead to isolate the VMs of
>>> the same level.
>>>
>> I think what he is after is the convenience of dynamic labeling, for
>> isolation.  Yes he could create new types for each instance, which every
>> virtual machine would need, this could cause a potential explosion in
>> the number of types and would be subject to failure.  It would be
>> putting a large onus on the Admin to manage all of these types.  The
>> real beauty of dynamic labeling is that it just works.
> 
> The types could be automatically generated from a template, and managed
> by libvirt in much the same way it presently manages categories.
> 
> In any event, he can do the same thing by use of categories rather than
> introducing an incomparable set of sensitivities, and that wouldn't
> require any changes to the policy toolchain or kernel security server.
> 

Well yes, but currently svirt can support out of the box ~500,000 svirt
instances,  If we when with  a type system, this would probably some
problems adding a couple of million types.  I don't think we want svirt
recompiling and loading policy every time it launches a virtual machine.
 :^)

Reserving a pool of categories at might be the way to go.  But at what
security level?  s15 or s0?  Also what about shared data between the
virtual machines, read only content.  Currently that is just labeled s0.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2jQXoACgkQrlYvE4MpobOVmACeKPS05jwZGV1alF/wM4w3Lunw
+wUAni9QZ/sBrNxxxCKZEYpKEZxEYkJi
=Ptgb
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: SELinux mixed/virtualisation policy

[chanson]

 

> > The types could be automatically generated from a template, and 
> > managed by libvirt in much the same way it presently 
> manages categories.
> > 
> > In any event, he can do the same thing by use of categories rather 
> > than introducing an incomparable set of sensitivities, and that 
> > wouldn't require any changes to the policy toolchain or 
> kernel security server.
> > 
> 
> Well yes, but currently svirt can support out of the box 
> ~500,000 svirt instances,  If we when with  a type system, 
> this would probably some problems adding a couple of million 
> types.  I don't think we want svirt recompiling and loading 
> policy every time it launches a virtual machine.
>  :^)
> 
> Reserving a pool of categories at might be the way to go.  
> But at what security level?  s15 or s0?  Also what about 
> shared data between the virtual machines, read only content.  
> Currently that is just labeled s0.
> 

I would suggest some level in between s0 and s15. I would agree with
Stephen that dynamic types would be preferred. I guess it just depends
on the reason you are using the MLS policy.

-Chad

 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/2011 04:44 PM, chanson@TrustedCS.com wrote:
>  
> 
>>> The types could be automatically generated from a template, and 
>>> managed by libvirt in much the same way it presently 
>> manages categories.
>>>
>>> In any event, he can do the same thing by use of categories rather 
>>> than introducing an incomparable set of sensitivities, and that 
>>> wouldn't require any changes to the policy toolchain or 
>> kernel security server.
>>>
>>
>> Well yes, but currently svirt can support out of the box 
>> ~500,000 svirt instances,  If we when with  a type system, 
>> this would probably some problems adding a couple of million 
>> types.  I don't think we want svirt recompiling and loading 
>> policy every time it launches a virtual machine.
>>  :^)
>>
>> Reserving a pool of categories at might be the way to go.  
>> But at what security level?  s15 or s0?  Also what about 
>> shared data between the virtual machines, read only content.  
>> Currently that is just labeled s0.
>>
> 
> I would suggest some level in between s0 and s15. I would agree with
> Stephen that dynamic types would be preferred. I guess it just depends
> on the reason you are using the MLS policy.
> 
> -Chad
> 
>  
Because you have virtual machines with data at different levels.

Of course you could have a multi-level virtual machine running with
multiple single level machines on the same multi-level virtual host.

Makes your head ache.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2jbJYACgkQrlYvE4MpobPZxACeMoZUpo678s8oPnkcG6BPvtUw
pKIAn37UKb80ghIqFzNyBr+4cxHxvZLD
=cSoU
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Stephen Smalley]

On Mon, 2011-04-11 at 13:59 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/11/2011 12:33 PM, Stephen Smalley wrote:
> > On Mon, 2011-04-11 at 11:24 -0400, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 04/11/2011 09:40 AM, Stephen Smalley wrote:
> >>> On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
> >>>> However, I and Dan Walsh (who kindly informed me about libvirt) both
> >>>> agree that dynamic labeling is more secure than manual labeling using
> >>>> MLS policy, for virtual machine environments.
> >>>
> >>> Can you elaborate on what your concern is there?  If it is merely that
> >>> two VMs at the same level are not isolated via the MLS policy, then that
> >>> isn't a MLS concern, and you could use TE instead to isolate the VMs of
> >>> the same level.
> >>>
> >> I think what he is after is the convenience of dynamic labeling, for
> >> isolation.  Yes he could create new types for each instance, which every
> >> virtual machine would need, this could cause a potential explosion in
> >> the number of types and would be subject to failure.  It would be
> >> putting a large onus on the Admin to manage all of these types.  The
> >> real beauty of dynamic labeling is that it just works.
> > 
> > The types could be automatically generated from a template, and managed
> > by libvirt in much the same way it presently manages categories.
> > 
> > In any event, he can do the same thing by use of categories rather than
> > introducing an incomparable set of sensitivities, and that wouldn't
> > require any changes to the policy toolchain or kernel security server.
> > 
> 
> Well yes, but currently svirt can support out of the box ~500,000 svirt
> instances,  If we when with  a type system, this would probably some
> problems adding a couple of million types.  I don't think we want svirt
> recompiling and loading policy every time it launches a virtual machine.
>  :^)
> 
> Reserving a pool of categories at might be the way to go.  But at what
> security level?  s15 or s0?  Also what about shared data between the
> virtual machines, read only content.  Currently that is just labeled s0.

I think this is where Ramon's idea breaks down.  The qemu process does
in fact need access to resources and other services on the host and thus
making the qemu process run in a context that is completely incomparable
with the contexts used by host processes and objects will quickly put
you into a situation where you must grant the qemu process MLS
overrides.  At which point you are no longer deriving much benefit from
the MLS policy at all.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/12/2011 09:50 AM, Stephen Smalley wrote:
> On Mon, 2011-04-11 at 13:59 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/11/2011 12:33 PM, Stephen Smalley wrote:
>>> On Mon, 2011-04-11 at 11:24 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 04/11/2011 09:40 AM, Stephen Smalley wrote:
>>>>> On Sun, 2011-04-10 at 14:12 -0300, Ramon de Carvalho Valle wrote:
>>>>>> However, I and Dan Walsh (who kindly informed me about libvirt) both
>>>>>> agree that dynamic labeling is more secure than manual labeling using
>>>>>> MLS policy, for virtual machine environments.
>>>>>
>>>>> Can you elaborate on what your concern is there?  If it is merely that
>>>>> two VMs at the same level are not isolated via the MLS policy, then that
>>>>> isn't a MLS concern, and you could use TE instead to isolate the VMs of
>>>>> the same level.
>>>>>
>>>> I think what he is after is the convenience of dynamic labeling, for
>>>> isolation.  Yes he could create new types for each instance, which every
>>>> virtual machine would need, this could cause a potential explosion in
>>>> the number of types and would be subject to failure.  It would be
>>>> putting a large onus on the Admin to manage all of these types.  The
>>>> real beauty of dynamic labeling is that it just works.
>>>
>>> The types could be automatically generated from a template, and managed
>>> by libvirt in much the same way it presently manages categories.
>>>
>>> In any event, he can do the same thing by use of categories rather than
>>> introducing an incomparable set of sensitivities, and that wouldn't
>>> require any changes to the policy toolchain or kernel security server.
>>>
>>
>> Well yes, but currently svirt can support out of the box ~500,000 svirt
>> instances,  If we when with  a type system, this would probably some
>> problems adding a couple of million types.  I don't think we want svirt
>> recompiling and loading policy every time it launches a virtual machine.
>>  :^)
>>
>> Reserving a pool of categories at might be the way to go.  But at what
>> security level?  s15 or s0?  Also what about shared data between the
>> virtual machines, read only content.  Currently that is just labeled s0.
> 
> I think this is where Ramon's idea breaks down.  The qemu process does
> in fact need access to resources and other services on the host and thus
> making the qemu process run in a context that is completely incomparable
> with the contexts used by host processes and objects will quickly put
> you into a situation where you must grant the qemu process MLS
> overrides.  At which point you are no longer deriving much benefit from
> the MLS policy at all.
> 
Not exactly. Could you give us an example of such a situation?

The processes representing virtual machine environments and its
associated resources should belong to the virtualisation sensitivities,
as well as the libvirt daemon. PCI passthrough should be a case a part,
as it needs to be detached from the host anyway--It should be explicitly
allowed and/or have a virtualisation sensitivity, which is the recommended.

Currently, the libvirt daemon executes with s0-s15:c0.c1023, which is
far more concerning than sv0-sv15:c0.c1023. So where is MLS?

So far we have been discussing how to accomplish what was proposed using
costly non standard methods and workarounds without considering the
benefits of a far more elegant solution, which until now does not seem
to have any downsides--despite the development effort.

We must consider that virtualisation is not something that is invented
every decade, and how much more we have the operating system and its
security mechanisms aware of it, is to be prepared for what comes next.


- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2leegACgkQkcIYeh81wLmNCgCfVsawKWHPyRVggTJVuN0OKz1v
x8oAn3rnlfGRNgdJO1ecMfqP0cGy/C4Y
=bxbs
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Stephen Smalley]

On Wed, 2011-04-13 at 07:24 -0300, Ramon de Carvalho Valle wrote:
> On 04/12/2011 09:50 AM, Stephen Smalley wrote:
> > I think this is where Ramon's idea breaks down.  The qemu process does
> > in fact need access to resources and other services on the host and thus
> > making the qemu process run in a context that is completely incomparable
> > with the contexts used by host processes and objects will quickly put
> > you into a situation where you must grant the qemu process MLS
> > overrides.  At which point you are no longer deriving much benefit from
> > the MLS policy at all.
> > 
> Not exactly. Could you give us an example of such a situation?
> 
> The processes representing virtual machine environments and its
> associated resources should belong to the virtualisation sensitivities,
> as well as the libvirt daemon. PCI passthrough should be a case a part,
> as it needs to be detached from the host anyway--It should be explicitly
> allowed and/or have a virtualisation sensitivity, which is the recommended.
> 
> Currently, the libvirt daemon executes with s0-s15:c0.c1023, which is
> far more concerning than sv0-sv15:c0.c1023. So where is MLS?

If you do a sesearch -A -s qemu_t, you'll see that qemu_t interacts with
quite a few types on the host, including both files and processes. And
even more so for libvirtd.  The more you move into your new
sensitivities, the more you'll have to define MLS overrides for more
domains.

At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
which is unsurprising since it is expected to create and manage VMs at
any level.  But qemu_t (i.e. the qemu process representing the
individual VM) is not given such MLS overrides, nor should it, as that
would allow to escape the confines of its level/range.
 
> So far we have been discussing how to accomplish what was proposed using
> costly non standard methods and workarounds without considering the
> benefits of a far more elegant solution, which until now does not seem
> to have any downsides--despite the development effort.

I can't quite see how your approach is cleaner than just using separate
categories.  Same effect - by allocating a dedicated category to the VMs
and another to the host, you end up with incomparable levels and thus
will achieve automatic isolation except where explicitly overridden
using the type attributes for MLS overrides.  Adding another
incomparable set of sensitivities puts us outside the scope of any
evaluated or even published security model.

Now something that has been suggested in the past would be adding
another level/range component to the security context for use by a
Biba-like integrity model.  That might be interesting, but would
obviously require quite a few changes on both the kernel and userland
side.  It would also require resolving the unfortunate ambiguity in the
current security context format.

> We must consider that virtualisation is not something that is invented
> every decade, and how much more we have the operating system and its
> security mechanisms aware of it, is to be prepared for what comes next.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2011 09:19 AM, Stephen Smalley wrote:
> If you do a sesearch -A -s qemu_t, you'll see that qemu_t interacts with
> quite a few types on the host, including both files and processes. And
> even more so for libvirtd.  The more you move into your new
> sensitivities, the more you'll have to define MLS overrides for more
> domains.
> 
> At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
> which is unsurprising since it is expected to create and manage VMs at
> any level.  But qemu_t (i.e. the qemu process representing the
> individual VM) is not given such MLS overrides, nor should it, as that
> would allow to escape the confines of its level/range.
Actually, processes representing virtual machine environments--when
initiated by libvirt--execute with svirt_t and not qemu_t, which also
belongs to virt_domain type attribute. So why the virt_domain rules
could not be moved to the virtualisation sensitivities?

> 
> I can't quite see how your approach is cleaner than just using separate
> categories.  Same effect - by allocating a dedicated category to the VMs
> and another to the host, you end up with incomparable levels and thus
> will achieve automatic isolation except where explicitly overridden
> using the type attributes for MLS overrides.  Adding another
> incomparable set of sensitivities puts us outside the scope of any
> evaluated or even published security model.
How dynamic labeling is supposed to work with this approach? We will
need a standard set of categories defined to libvirt use.

> 
> Now something that has been suggested in the past would be adding
> another level/range component to the security context for use by a
> Biba-like integrity model.  That might be interesting, but would
> obviously require quite a few changes on both the kernel and userland
> side.  It would also require resolving the unfortunate ambiguity in the
> current security context format.
Please, correct if I am wrong, but from what I understand adding another
level and range component will just add another level of hierarchy for
multiple set of sensitivities and categories (i.e.
s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
virtualised sensitivities should be below or above the standard
sensitivities in this new level and range component?


- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2lnzgACgkQkcIYeh81wLmQIQCbBvbodiOvSYza2/8vchTy27Hx
9OoAniLBlWTRKSlUDf16BZovzm8GVWJG
=JBO/
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Russell Coker]

On Wed, 13 Apr 2011, Ramon de Carvalho Valle <rcvalle@linux.vnet.ibm.com> 
wrote:
> > Now something that has been suggested in the past would be adding
> > another level/range component to the security context for use by a
> > Biba-like integrity model.  That might be interesting, but would
> > obviously require quite a few changes on both the kernel and userland
> > side.  It would also require resolving the unfortunate ambiguity in the
> > current security context format.
> 
> Please, correct if I am wrong, but from what I understand adding another
> level and range component will just add another level of hierarchy for
> multiple set of sensitivities and categories (i.e.
> s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
> virtualised sensitivities should be below or above the standard
> sensitivities in this new level and range component?

For at least 10 years there has been a general plan to use the role field in 
the on-disk labels.  Now we are just starting work on it.  Using the role 
field has clear benefits but it's taken this long because there are plenty of 
other things to work on and work-arounds for the need for it.

That said, I think that there are many potential benefits for adding more 
fields to the sensitivity label.  One thing that I think would be useful would 
be to have a field that can be used as a default-creation level for files.  
Setting the create context works well enough for a process but isn't inherited 
by child processes.

It would be interesting to setup a Biba/BLP policy as a test too, if nothing 
else that would be a good demonstration for people who think that the current 
MLS is too confusing.  :-#

I'm sure we could find other uses if it was implemented.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Stephen Smalley]

On Wed, 2011-04-13 at 10:03 -0300, Ramon de Carvalho Valle wrote:
> On 04/13/2011 09:19 AM, Stephen Smalley wrote:
> > At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
> > which is unsurprising since it is expected to create and manage VMs at
> > any level.  But qemu_t (i.e. the qemu process representing the
> > individual VM) is not given such MLS overrides, nor should it, as that
> > would allow to escape the confines of its level/range.
> Actually, processes representing virtual machine environments--when
> initiated by libvirt--execute with svirt_t and not qemu_t, which also
> belongs to virt_domain type attribute. So why the virt_domain rules
> could not be moved to the virtualisation sensitivities?

The same is true for svirt_t - if you look at the policy, you'll see
that it interacts with various host processes and accesses various host
files.  You can't push all of those into your new sensitivities, and
thus the end result will be that you'll have to allow interactions
between the "regular" sensitivities and the "virtualization"
sensitivities, thereby adding more exceptions to the MLS constraints.

> > I can't quite see how your approach is cleaner than just using separate
> > categories.  Same effect - by allocating a dedicated category to the VMs
> > and another to the host, you end up with incomparable levels and thus
> > will achieve automatic isolation except where explicitly overridden
> > using the type attributes for MLS overrides.  Adding another
> > incomparable set of sensitivities puts us outside the scope of any
> > evaluated or even published security model.
> How dynamic labeling is supposed to work with this approach? We will
> need a standard set of categories defined to libvirt use.

Yes, you just need to standardize some allocation for libvirt, which
realistically ought to be done anyway, since we already have other users
of categories like sandbox.

> > Now something that has been suggested in the past would be adding
> > another level/range component to the security context for use by a
> > Biba-like integrity model.  That might be interesting, but would
> > obviously require quite a few changes on both the kernel and userland
> > side.  It would also require resolving the unfortunate ambiguity in the
> > current security context format.
> Please, correct if I am wrong, but from what I understand adding another
> level and range component will just add another level of hierarchy for
> multiple set of sensitivities and categories (i.e.
> s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
> virtualised sensitivities should be below or above the standard
> sensitivities in this new level and range component?

Having another level/range component (or more generally, an extensible
list of level/range components) would more easily delineate multiple
uses of the level/range for different purposes.  So you could have
simultaneous MLS+libvirt dynamic labeling without needing to worry about
allocation of categories between them.  Or you could have simultaneous
MLS+Biba.  Or all three (if extensible).
 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2011 09:51 AM, Stephen Smalley wrote:
> On Wed, 2011-04-13 at 10:03 -0300, Ramon de Carvalho Valle wrote:
>> On 04/13/2011 09:19 AM, Stephen Smalley wrote:
>>> At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
>>> which is unsurprising since it is expected to create and manage VMs at
>>> any level.  But qemu_t (i.e. the qemu process representing the
>>> individual VM) is not given such MLS overrides, nor should it, as that
>>> would allow to escape the confines of its level/range.
>> Actually, processes representing virtual machine environments--when
>> initiated by libvirt--execute with svirt_t and not qemu_t, which also
>> belongs to virt_domain type attribute. So why the virt_domain rules
>> could not be moved to the virtualisation sensitivities?
> 
> The same is true for svirt_t - if you look at the policy, you'll see
> that it interacts with various host processes and accesses various host
> files.  You can't push all of those into your new sensitivities, and
> thus the end result will be that you'll have to allow interactions
> between the "regular" sensitivities and the "virtualization"
> sensitivities, thereby adding more exceptions to the MLS constraints.
> 
>>> I can't quite see how your approach is cleaner than just using separate
>>> categories.  Same effect - by allocating a dedicated category to the VMs
>>> and another to the host, you end up with incomparable levels and thus
>>> will achieve automatic isolation except where explicitly overridden
>>> using the type attributes for MLS overrides.  Adding another
>>> incomparable set of sensitivities puts us outside the scope of any
>>> evaluated or even published security model.
>> How dynamic labeling is supposed to work with this approach? We will
>> need a standard set of categories defined to libvirt use.
> 
> Yes, you just need to standardize some allocation for libvirt, which
> realistically ought to be done anyway, since we already have other users
> of categories like sandbox.
> 
>>> Now something that has been suggested in the past would be adding
>>> another level/range component to the security context for use by a
>>> Biba-like integrity model.  That might be interesting, but would
>>> obviously require quite a few changes on both the kernel and userland
>>> side.  It would also require resolving the unfortunate ambiguity in the
>>> current security context format.
>> Please, correct if I am wrong, but from what I understand adding another
>> level and range component will just add another level of hierarchy for
>> multiple set of sensitivities and categories (i.e.
>> s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
>> virtualised sensitivities should be below or above the standard
>> sensitivities in this new level and range component?
> 
> Having another level/range component (or more generally, an extensible
> list of level/range components) would more easily delineate multiple
> uses of the level/range for different purposes.  So you could have
> simultaneous MLS+libvirt dynamic labeling without needing to worry about
> allocation of categories between them.  Or you could have simultaneous
> MLS+Biba.  Or all three (if extensible).
>  

I will open a bugzilla with libvirt to allow the admin to specify a
sensitivity and a range of MCS labels to randomly choose between.  This
might be necessary for an other use case that suddenly seems to be
picking up steam, labeled NFS.  If Labeled NFS happens we need a way to
make sure two libvirt instances do not choose the same Categories, to
start virtual machines.


Sandbox MCS and SVirt MCS and any other MCS (Coming soon) should still
be isolated by type enforcement rules.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2lrL8ACgkQrlYvE4MpobPTaQCfSiOElDU7Ncpr3RahZIAMqnxG
N5IAnjwV7vn+FRysCBY6KWV72KneHvj2
=fDFD
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2011 10:51 AM, Stephen Smalley wrote:
> On Wed, 2011-04-13 at 10:03 -0300, Ramon de Carvalho Valle wrote:
>> On 04/13/2011 09:19 AM, Stephen Smalley wrote:
>>> At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
>>> which is unsurprising since it is expected to create and manage VMs at
>>> any level.  But qemu_t (i.e. the qemu process representing the
>>> individual VM) is not given such MLS overrides, nor should it, as that
>>> would allow to escape the confines of its level/range.
>> Actually, processes representing virtual machine environments--when
>> initiated by libvirt--execute with svirt_t and not qemu_t, which also
>> belongs to virt_domain type attribute. So why the virt_domain rules
>> could not be moved to the virtualisation sensitivities?
> 
> The same is true for svirt_t - if you look at the policy, you'll see
> that it interacts with various host processes and accesses various host
> files.  You can't push all of those into your new sensitivities, and
> thus the end result will be that you'll have to allow interactions
> between the "regular" sensitivities and the "virtualization"
> sensitivities, thereby adding more exceptions to the MLS constraints.
Not if these objects also have the virtualisation sensitivities assigned
to them (i.e. s0,sv0).

> 
>>> I can't quite see how your approach is cleaner than just using separate
>>> categories.  Same effect - by allocating a dedicated category to the VMs
>>> and another to the host, you end up with incomparable levels and thus
>>> will achieve automatic isolation except where explicitly overridden
>>> using the type attributes for MLS overrides.  Adding another
>>> incomparable set of sensitivities puts us outside the scope of any
>>> evaluated or even published security model.
>> How dynamic labeling is supposed to work with this approach? We will
>> need a standard set of categories defined to libvirt use.
> 
> Yes, you just need to standardize some allocation for libvirt, which
> realistically ought to be done anyway, since we already have other users
> of categories like sandbox.
Well, I think this is what will happen in the end of this discussion anyway.

> 
>>> Now something that has been suggested in the past would be adding
>>> another level/range component to the security context for use by a
>>> Biba-like integrity model.  That might be interesting, but would
>>> obviously require quite a few changes on both the kernel and userland
>>> side.  It would also require resolving the unfortunate ambiguity in the
>>> current security context format.
>> Please, correct if I am wrong, but from what I understand adding another
>> level and range component will just add another level of hierarchy for
>> multiple set of sensitivities and categories (i.e.
>> s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
>> virtualised sensitivities should be below or above the standard
>> sensitivities in this new level and range component?
> 
> Having another level/range component (or more generally, an extensible
> list of level/range components) would more easily delineate multiple
> uses of the level/range for different purposes.  So you could have
> simultaneous MLS+libvirt dynamic labeling without needing to worry about
> allocation of categories between them.  Or you could have simultaneous
> MLS+Biba.  Or all three (if extensible).
This still implies an hierarchy between these multiple set of
sensitivities and categories.

> 

- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2l7FMACgkQkcIYeh81wLmJ+gCePDH3/jupKn8vKwKGBO+Q29rS
R1UAn1Z7ijj/t+24eZrqgg0eaSjhOEha
=kzxp
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Ramon de Carvalho Valle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2011 11:01 AM, Daniel J Walsh wrote:
> On 04/13/2011 09:51 AM, Stephen Smalley wrote:
>> On Wed, 2011-04-13 at 10:03 -0300, Ramon de Carvalho Valle wrote:
>>> On 04/13/2011 09:19 AM, Stephen Smalley wrote:
>>>> At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
>>>> which is unsurprising since it is expected to create and manage VMs at
>>>> any level.  But qemu_t (i.e. the qemu process representing the
>>>> individual VM) is not given such MLS overrides, nor should it, as that
>>>> would allow to escape the confines of its level/range.
>>> Actually, processes representing virtual machine environments--when
>>> initiated by libvirt--execute with svirt_t and not qemu_t, which also
>>> belongs to virt_domain type attribute. So why the virt_domain rules
>>> could not be moved to the virtualisation sensitivities?
> 
>> The same is true for svirt_t - if you look at the policy, you'll see
>> that it interacts with various host processes and accesses various host
>> files.  You can't push all of those into your new sensitivities, and
>> thus the end result will be that you'll have to allow interactions
>> between the "regular" sensitivities and the "virtualization"
>> sensitivities, thereby adding more exceptions to the MLS constraints.
> 
>>>> I can't quite see how your approach is cleaner than just using separate
>>>> categories.  Same effect - by allocating a dedicated category to the VMs
>>>> and another to the host, you end up with incomparable levels and thus
>>>> will achieve automatic isolation except where explicitly overridden
>>>> using the type attributes for MLS overrides.  Adding another
>>>> incomparable set of sensitivities puts us outside the scope of any
>>>> evaluated or even published security model.
>>> How dynamic labeling is supposed to work with this approach? We will
>>> need a standard set of categories defined to libvirt use.
> 
>> Yes, you just need to standardize some allocation for libvirt, which
>> realistically ought to be done anyway, since we already have other users
>> of categories like sandbox.
> 
>>>> Now something that has been suggested in the past would be adding
>>>> another level/range component to the security context for use by a
>>>> Biba-like integrity model.  That might be interesting, but would
>>>> obviously require quite a few changes on both the kernel and userland
>>>> side.  It would also require resolving the unfortunate ambiguity in the
>>>> current security context format.
>>> Please, correct if I am wrong, but from what I understand adding another
>>> level and range component will just add another level of hierarchy for
>>> multiple set of sensitivities and categories (i.e.
>>> s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
>>> virtualised sensitivities should be below or above the standard
>>> sensitivities in this new level and range component?
> 
>> Having another level/range component (or more generally, an extensible
>> list of level/range components) would more easily delineate multiple
>> uses of the level/range for different purposes.  So you could have
>> simultaneous MLS+libvirt dynamic labeling without needing to worry about
>> allocation of categories between them.  Or you could have simultaneous
>> MLS+Biba.  Or all three (if extensible).
> 
> 
> I will open a bugzilla with libvirt to allow the admin to specify a
> sensitivity and a range of MCS labels to randomly choose between.  This
> might be necessary for an other use case that suddenly seems to be
> picking up steam, labeled NFS.  If Labeled NFS happens we need a way to
> make sure two libvirt instances do not choose the same Categories, to
> start virtual machines.
Thank you very much Daniel. Please, add me to the Bugzilla.

> 
> 
> Sandbox MCS and SVirt MCS and any other MCS (Coming soon) should still
> be isolated by type enforcement rules.

- -- 
Ramon de Carvalho Valle
Security Engineer
IBM Linux Technology Center
rcvalle@linux.vnet.ibm.com
http://rcvalle.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2l7IwACgkQkcIYeh81wLlxGQCfQAsutMPdC30n4vohwYWXecrV
EFQAoI/FBn2C77vkkkRkePZNN/jntStF
=MbKr
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux mixed/virtualisation policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2011 02:32 PM, Ramon de Carvalho Valle wrote:
> On 04/13/2011 10:51 AM, Stephen Smalley wrote:
>> On Wed, 2011-04-13 at 10:03 -0300, Ramon de Carvalho Valle wrote:
>>> On 04/13/2011 09:19 AM, Stephen Smalley wrote:
>>>> At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides,
>>>> which is unsurprising since it is expected to create and manage VMs at
>>>> any level.  But qemu_t (i.e. the qemu process representing the
>>>> individual VM) is not given such MLS overrides, nor should it, as that
>>>> would allow to escape the confines of its level/range.
>>> Actually, processes representing virtual machine environments--when
>>> initiated by libvirt--execute with svirt_t and not qemu_t, which also
>>> belongs to virt_domain type attribute. So why the virt_domain rules
>>> could not be moved to the virtualisation sensitivities?
> 
>> The same is true for svirt_t - if you look at the policy, you'll see
>> that it interacts with various host processes and accesses various host
>> files.  You can't push all of those into your new sensitivities, and
>> thus the end result will be that you'll have to allow interactions
>> between the "regular" sensitivities and the "virtualization"
>> sensitivities, thereby adding more exceptions to the MLS constraints.
> Not if these objects also have the virtualisation sensitivities assigned
> to them (i.e. s0,sv0).
> 
> 
>>>> I can't quite see how your approach is cleaner than just using separate
>>>> categories.  Same effect - by allocating a dedicated category to the VMs
>>>> and another to the host, you end up with incomparable levels and thus
>>>> will achieve automatic isolation except where explicitly overridden
>>>> using the type attributes for MLS overrides.  Adding another
>>>> incomparable set of sensitivities puts us outside the scope of any
>>>> evaluated or even published security model.
>>> How dynamic labeling is supposed to work with this approach? We will
>>> need a standard set of categories defined to libvirt use.
> 
>> Yes, you just need to standardize some allocation for libvirt, which
>> realistically ought to be done anyway, since we already have other users
>> of categories like sandbox.
> Well, I think this is what will happen in the end of this discussion anyway.
> 
> 
>>>> Now something that has been suggested in the past would be adding
>>>> another level/range component to the security context for use by a
>>>> Biba-like integrity model.  That might be interesting, but would
>>>> obviously require quite a few changes on both the kernel and userland
>>>> side.  It would also require resolving the unfortunate ambiguity in the
>>>> current security context format.
>>> Please, correct if I am wrong, but from what I understand adding another
>>> level and range component will just add another level of hierarchy for
>>> multiple set of sensitivities and categories (i.e.
>>> s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the
>>> virtualised sensitivities should be below or above the standard
>>> sensitivities in this new level and range component?
> 
>> Having another level/range component (or more generally, an extensible
>> list of level/range components) would more easily delineate multiple
>> uses of the level/range for different purposes.  So you could have
>> simultaneous MLS+libvirt dynamic labeling without needing to worry about
>> allocation of categories between them.  Or you could have simultaneous
>> MLS+Biba.  Or all three (if extensible).
> This still implies an hierarchy between these multiple set of
> sensitivities and categories.
> 
> 
> 

- --
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.

Open Bugzilla for libvirt to accept a range of categories and a
sensitivity level to launch virtual machines.

https://bugzilla.redhat.com/show_bug.cgi?id=696292
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2l9NQACgkQrlYvE4MpobNyggCfQ6snx0DNhz216cCqP8s9BiCk
tAYAn1vGpsLOyQAOO7m64MlzNMBSjOqA
=6HKl
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.