Nautilus integration with SELinux

[Ivan Gyurdiev <ivg2 cornell edu>]

Hi,

Red Hat would like to improve integration between SELinux and Nautilus. 
We would like to have nautilus display, and allow the user to modify 
SELinux related security properties of files and directories. I wanted 
to get some feedback and suggestions on a possible UI for this. The 
current permissions tab looks cluttered, and I'm not sure what's the 
best way to add selinux support to it. Should we have a new tab for 
this? What should it look like?

Below is some background, and some ideas, but any further suggestions 
are appreciated:

=======================
A selinux context is composed of 4 fields ->  user: role: type: mls
We would like to expose field 3 (type) and field 4 (mls) to the user.
Field 1 (user) and Field 2 (role) have no security significance at the 
moment when used on files and directories, so I think we don't need to 
show those to the user. Field 1 can be used to tell which selinux user 
created the file, but it only provides information, and no enforcement 
at the moment.
=======================

Field 3 (type) is an ascii string, which looks like: user_home_t, 
shadow_t. It's the most important field in type enforcement. It 
determines what domains (types of processes) have access to this file. 
There's a single string associated with each file.

This string can't be any random string - it has to be a valid type 
defined in the security policy. It has to be a "file type", not 
something used to label processes.  Furthermore, the user has to have 
the permission to relabel things to be of this type.

In view of the above, I think it would be preferable if we could 
enumerate all the types available for a user, and provide some kind of a 
selection UI. However, I don't know if we'll have the capability to do 
that soon in libselinux, so an alternative would be a box where the user 
types the context, and it is validated (when should it be validated?)

========================

Field 4 (mls) is an ascii string, which looks like this in raw format: 
s0-s1:c0,c1,c2.c10,c255. The above is saying the user has clearance for 
security levels s0, and s1, and categories c0, c1, c2 through c10, and 
c255. The security levels are hierarchical, and have to do with the MLS 
(multi-level security) policy. More important to us are the categories 
(c*), which are organized in flat-hierarchy, and work like this: if you 
mark your file in a certain category, then only other users with access 
to the same category can access that file.

The above is not very user friendly, which is why there is a translation 
to something like this:

# s0:c0=CompanyConfidential
# s0:c1=PatientRecord
# s0:c2=Unclassified
# s0:c3=TopSecret
# s0:c1,c3=CompanyConfidentialRedHat

The translation is controlled by the semanage utility, and we'll also be 
writing GUI tools for that.

Here's a URL which explains this much better than I can:
http://james-morris.livejournal.com/8228.html

The important point to understand here is that the user has access to 
certain categories and security clearances.We can obtain those (from 
libselinux), enumerate them, translate them into admin-configurable 
strings that make sense, and present them to the user as a list to 
choose from. A single mls field can correspond to many of those strings, 
as the encoding above showed - you are choosing from a list of 
categories to place your file in.

It does not make sense to have a box for the user to type in categories, 
because we can enumerate those.

One thing that would make sense is a list of checkboxes for each 
(sensitivity, category) string. However, there could be many of those 
sensitivity/category strings configured on the machine. A possibly 
better approach would be to only present the categories that the file is 
currently marked in, and to have an add dialog to add more categories, 
where you can select from the ones available.

Also, I'm not sure if anyone uses those nautilus emblems for anything, 
but it seems they would be potentially useful if integrated with MLS labels.
==================================
I've been assigned to this project, and I'm unfamiliar with 
gnome/nautilus development practices, so if there are important things I 
need to know, please point those out - I am looking forward to working 
with gnome and nautilus developers.

=================
At the moment I'm looking at adding gnome-vfs support for reading and 
writing the selinux context (file method), but this doesn't look 
terribly difficult (I am working from Dan Walsh's previous patches in 
this area, making some changes), so I'll switch focus to nautilus soon.