[redhat-lspp] Making MCS mandatory

[Russell Coker]

I'm posting to this list first as mandatory security is of interest to
everyone here.  I'll post to the main SE Linux list tomorrow if no-one
points out any serious problems with my ideas.  I plan to put this in
rawhide in a couple of days if no-one points out serious problems.

The low level of the range for a process determines the default context
for a created file.  The default configuration of the MCS policy has a
low level of "s0" for all user login sessions.  I believe that the vast
majority of systems will not differ from the default in this regard.
Therefore what I propose below will not make an impact on most users.
Targeted policy is designed to be minimally invasive, I expect that at
least 90% of Fedora users don't notice it's presence or even know that
it is there.  MCS is an extension to the same theme, people who use
targeted policy can choose to ignore it (whether they have no interest
in SE Linux or just no interest in anything other than the domain-type
model) and it won't affect them.  Mandatory MCS will be just as
minimally invasive to MCS users.  People who really use MCS now (as
opposed to people who just have the default configuration and have
everything running at s0-s0:c0.c255) will probably have all accounts
with s0 as the low level and thus notice no immediate difference from my
changes.

The latest MCS policy does not permit increases in the high level of the
sensitivity range except through logging in again, but does allow
changes to the low level without restriction.

For MCS to be a mandatory policy there would need to be controls over
changing the low level of the range for a child process.  So if the
process was not permitted to lower the low level of it's range then it
would be mandatory for all files created by the user to have all
categories assigned to the low level of their range.  Similar
restrictions would also be needed on file relabel, ptrace, etc.

Finally if the low level of the process range is not dominated by the
level of a file then writes to the file would be denied.  This final
point could potentially make a Mandatory MCS system difficult to use,
however as such a configuration is optional (as explained in para 1) it
should not cause any problems.

The changes to the MCS constraints are:

For file write operations { write setattr append unlink link rename
create relabelto } I added ((l1 domby l2) or (t2 == mcstrustedobject)).

The mcstrustedobject attribute is an analogy of mlstrustedobject.  I am
only using it to override the mandatory access of the file (currently
the only file type in question that matches is security_t and I want the
high level enforced, if we extend MCS to control access to device nodes
then we will still want it this way as the devices in question all
default to s0).  Let me know if you think I should use a different
attribute name for this.

For process transition and dyntransition I changed ( h1 dom h2 ) to
( ( h1 dom h2 ) and ((l1 domby l2) or (t1 == mcssetlow)) ).  Note that I
haven't actually used the mcssetlow attribute yet.  If you think that
mcssetlow is a bad name then please suggest another.

For ptrace I added (l1 domby l2) to the constraint.  This prevents a
process from escaping from it's level by ptracing a process which runs
at a lower level.

Finally as an independent issue to MMCS I have put the more important
parts of /selinux as c0.c255.

Here is a summary of the differences between Mandatory MCS and MLS:

MLS bases read access controls on the effective clearance (the low level
of the range) and thus effective read access equals the minimum level
for writes.  This makes it impossible to relabel data to a lower level.
In MCS it is sometimes desirable that discretion to relabel data to a
lower level be granted.  So a user running at s0:c0.c10:s0:c0.c100 can
read a file that has s0:c11 and write the data to a file running at
s0:c0.c10.  This is considered a benefit in the MCS design, the user has
some categories for which they have discretionary access and some for
which the access is mandatory.  Which categories are mandatory is
initially determined by the administrator through semanage, but can also
be determined by the user for their child processes.  Under MMCS if my
shell runs at s0:c1-s0:c0.c10 I can run the command
"runcon -l s0:c1.c2-s0:c1.c4 bash" and then prevent all further
processes from accessing data with categories c0 and c5.c10 and also
forcing all written data to have categories c1.c2.

The RPMs for rawhide and the patch are at the following URL:
http://people.redhat.com/rcoker/pol/