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

[Stephen Smalley]

On Fri, 2007-01-26 at 13:39 -0600, Darrel Goeddel wrote:
> 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)?

I think it will prove difficult to maintain distinct levels on distinct
files under /etc/selinux/mls, particularly given the way in which the
files are regenerated upon updates by semanage/semodule (including the
complete re-creation of the modules/active subtree on each transaction).
range_transition can only help when you have a distinct type on the
parent directory and can't help at all when dealing with multiple files
within a single parent directory (e.g. if you want to distinguish just
setrans.conf and not seusers or just specific files under modules/).

Making all of the files under /etc/selinux/mls SystemHigh would be
simpler (just run semanage/semodule at SystemHigh too), but will prevent
any use of those files by any process that either is not SystemHigh or
lacks MLS overrides.  Not sure to what extent that is an issue.

Making all of the files under /etc/selinux/mls SystemLow would also be
simpler, but might not be acceptable in some cases (as you describe).
But not clear that it matters from an LSPP point of view per se.

-- 
Stephen Smalley
National Security Agency