[redhat-lspp] Just noticed a problem with semanage/semodule and SELinux policy

[Darrel Goeddel]

Stephen Smalley wrote:
> On Thu, 2007-01-25 at 06:57 -0500, Stephen Smalley wrote:
>> On Wed, 2007-01-24 at 16:37 -0500, Daniel J Walsh wrote:
>>> Currently you can run semanage/semodule at SystemLow and they end up 
>>> creating files in /etc/selinux/mls/seusers and 
>>> /etc/selinux/mls/policy/policy.21 at SystemLow.

Those commands should probably not be able to overwrite systemhigh data with
systemlow data (as most things should not be able to do this).

>>> The system defaults say they should be at SystemHigh.  I am not sure why 
>>> they are specified at SystemHigh, but we either need to change the 
>>> specification or lots of other files need to be moved to system high and 
>>> perhaps only allow semanage to run at SystemHigh. 

The theory is that these files can contain the lables up to systemhigh.  The
mere existence of the label is classified just like data having that label.
Since the seusers file contains the clearances, those labels need to be
protected with the appropriate labels (ain't that fun...).  This is same
reason that the label translation daemon will not translate things for
you if you are not cleared to know about the translation.  We are trying
to prevent someone who is cleared at secret (let's say s7) to be able
to read the seusers file and find out that the label (s10:c0-c100) is in
use on the system, possibly indicating that the machine is a higher-value
target.  I hope that is the appropriate rationale, Chad may correct me if
needed :)

>>> Running semanage at SystemHigh, ends up creating a bunch of files at 
>>> SystemHigh that should be SystemLow, also.  So no easy fix.
>>
>> Running semanage/semodule at SystemLow and using range_transition to
>> transition the files to SystemHigh may work.  But are they truly
>> SystemHigh in their data?
> 
> And what inputs to them are considered SystemHigh, as those files would
> need to be kept at SystemHigh as well?

By the above explanation, the policy modules living in /usr/share/selinux
would also be protected at systemhigh because they can include label
information (range_transitions, mls definitions, etc.).

> range_transition may be insufficiently granular if you want to keep some
> of the policy files at SystemLow and others at SystemHigh; we would need
> libsemanage to call matchpathcon() and setfscreatecon() on each file it
> creates.

Yep, or we could retype some files so the range_transitions could be defined
more granularly.

Personally, I'm not sure that all of it is necessary - that requirement needs
to be laid out evaluators, certifiers, accreditors, etc.  Any other opinions
on this?  I would keep the human readable translations protected with the
current scheme.  Can we argue the distinction between human readable label
protections and binary form (which could also encompass the selinux native
string format since it just represents the numeric values)?

-- 

Darrel