5:34 a.m.
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
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|