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

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.

>> 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'

>> 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).

>> >> 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-----