[libvirt] RFC: extending sVirt to confine host apps which talk to libvirtd

[Daniel J Walsh]

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

On 06/08/2011 06:34 AM, Daniel P. Berrange wrote:
> On Mon, Jun 06, 2011 at 02:51:15PM -0400, Daniel J Walsh wrote:
>> On 06/06/2011 10:41 AM, Daniel P. Berrange wrote:
>>> Technical Notes / Issues
>>> ------------------------
>>>
>>> 1. Adding new SELinux security classes / access vectors
>>>
>>> The selinux security classes are defined in /usr/include/selinux/flask.h
>>> and access vectors in /usr/include/selinux/av_permissions.h Both of these
>>> files are automatically by a script in the selinux reference policy code
>>> '$serefpolicy/policy/flask/flask.py'. The master data files are in the
>>> same directory, 'access_vectors' and 'security_classes'. Once generated,
>>> the headers need to be manually copied into the libselinux package
>>> sources.
>>>
>> You do  not need to do this anymore.  libselinux does not care about the
>> access vectors, they are named in your application.Well
> 
> AFAICT, when I invoke avc_has_perm(), the security_class_t and
> access_vector_t parameters are integer constants that come from
> selinux/flask.h and selinux/av_permissions.h respectively. While
> I could just pick some unused numbers myself and hardcode in the
> libvirt source, it seems like it is better to have them recorded
> in those header files deployed by libselinux, so libvirt's usage
> doesn't clash with some other future app.
> 
There are calls now that ask the kernel for the correct numbers.
 man security_av_string


>>> 3. Security labelling config modes
>>>
>>> When creating a guest the following XML snippets can be used.
>>>
>>>   a. Default type, dynamic MCS, automatic relabelling
>>>
>>>      <seclabel type='selinux' mode='dynamic' relabel='yes'/>
>>>
>>>
>>>   b. Custom type, dynamic MCS, automatic relabelling
>>>
>>>      <seclabel type='selinux' mode='hybrid' relabel='yes'>
>>>         <label>system_u:system_r:mysvirt_t</label>
>>>         <imagelabel>system_u:object_r:mysvirt_image_t</imagelabel>
>>>      </seclabel>
>>>
>> Yes this would be cool, although I am not sure you need an image label,
>> since the MCS separation would still work on svirt_image_t.  Would make
>> policy writing easier and selection easier if you did not change the
>> type of the image file.
>>
>> I would at least allow for the admin to not specify a image label.
> 
> Yes, now that you mention it,  including the imagelabel does
> seem redundant here.
> 
> Once we can have multiple different base labels, should we control
> uniqueness just on the MCS category, or the full label. I believe
> we still want the former.
> 
> eg, we should forbid two different guests to run:
> 
>   'myfirst_svirt_t:c123,435'
>   'myother_svirt_t:c123,435'
> 
Yes I would keep one table of MCS Strings unique and never allow two
process the same label.


>>>   c. Default type, dynamic MCS, no relabelling
>>>
>>>      <seclabel type='selinux' mode='dynamic' relabel='no'/>
>>>
>>>      Does this mode make any sense, since admin doesn't know
>>>      MCS category upfront ? Possibly only useful if the guest
>>>      only has readonly disks.
>>>
>> But you don't relabel on readonly correct, since this is a shared
>> resource.  I would say this would not be used.
> 
> We do actually relabel readonly content, but to the shared
> label (if it doesn't already have the right shared label).
> 
Ok
>>>
>>>   d. Custom type, dynamic MCS, no relabelling
>>>
>>>      <seclabel type='selinux' mode='hybrid' relabel='no'>
>>>         <label>system_u:system_r:mysvirt_t</label>
>>>      </seclabel>
>>>
>>>      Same question about whether it makes sense
>>>
>> I don't think this makes sense.
>>>
>>>   e. Custom type, static MCS, auto relabelling
>>>
>>>      <seclabel type='selinux' mode='static' relabel='yes'>
>>>         <label>system_u:system_r:mysvirt_t:s0:c123,c456</label>
>>>         <imagelabel>system_u:system_r:mysvirt_image_t:s0:c123,c456</imagelabel>
>>>      </seclabel>
>>>
>>>
>> This is fine, not sure it is legal in MLS  world.  Although I guess we
>> could change the label to SystemHigh when not in use.
> 
> Yep, or just have MLS policy block this scenario.
> 
>>>   f. Custom type, static MCS, no relabelling
>>>
>>>      <seclabel type='selinux' mode='static' relabel='no'>
>>>         <label>system_u:system_r:mysvirt_t:s0:c123,c456</label>
>>>      </seclabel>
>>>
>>>
>> We have this now, this is static labeling.
> 
> Correct, options a. and f. are the two current configs we
> support.
> 
>> One last thing to think about is since libvirt can now be run under the
>> users context, in certain situations, libvirt should examine the range
>> of MLS/MCS labels associated with it and make sure that it can only
>> assign MCS labels within this range.
>>
>> For example if I am a user running as
>>
>> staff_t:s0-s0:c500
>>
>> libvirt should only pick random labels between 0-500.
> 
> Ah, interesting point.
> 
> 
> Daniel

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

iEYEARECAAYFAk3ww3AACgkQrlYvE4MpobND+wCgoI2cK6qFOLspFe+MltnlqjwA
hmwAnAuYytuZMf2tDPJphrQJ16IxXJjq
=ShL0
-----END PGP SIGNATURE-----