-----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----- -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list