SELinux mixed/virtualisation policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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@xxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux