[redhat-lspp] LSPP/RBACPP requirements v.002

[Stephen Smalley]

On Tue, 2005-08-30 at 19:40 -0500, George Wilson wrote:
> This is my take on the work items required to meet LSPP and RBACPP. It
> is
> loosely based on the previous requirements list James Morris posted
> some time
> ago. It also incorporates the thoughts of many others. Standard
> disclaimers
> apply: it may be incomplete, likely contains inaccuracies, certainly
> contains
> misspellings, is not a legal commitment, represents my opinion, not
> IBM's, etc.
> In particular, the developers listed are merely suggestions. Please
> help make
> corrections and sign up for some items that interest you.

A few comments/questions:

- The "MLS policy and function requirement" says that we need a "real"
MLS policy still.  I assume TCS has one, is it available?  Also, ideally
we'd like to see the reference policy (with MCS and MLS changes
included) used as the baseline for the effort if it matures in time.

- The "Enhance and test, or restrict, file archivers" requirement
mentions star as an option.  I believe that dump/restore has added xattr
support upstream and this is included in Fedora.  rsync in Fedora also
has an xattr patch to support preserving xattrs.  Hence, they seem to be
other options.  We originally had a patch for GNU tar as well (specific
to preserving SELinux attributes), but that was discarded during the
Fedora integration due to the availability of the star support.  

- With regard to the state of the "Label translation" requirement,
libselinux upstream and in Fedora now includes the necessary
infrastructure to support transparent label translations for
applications that use it.  TCS has a patch for procps to make it use
libselinux rather than directly reading /proc/pid/attr/current so that
it will also use the translations, and has submitted it upstream.
Fedora has a libsetrans that performs the actual translation for their
MCS policy, but we'll need to generalize it or drop in a different one
for MLS I think.  I assume TCS has one, but I think it then communicates
with a daemon that internally uses the MITRE library.  MITRE was open to
the idea of open sourcing their library, but TCS didn't seem to think
that would be worthwhile versus just creating a clean reimplementation
for anyone who isn't bound to using the MITRE one.  Not sure what others
think.

- I'm a bit unclear on the "Multilevel xinetd" and "Multilevel sshd"
requirements.  Using the label of the incoming connection implies an
obvious trust burden on the client, and that is all done prior to any
normal user authentication mechanisms by the application, so it may have
little relevance to the actual authorized label for the user.  The sshd
selinux patch performs explicit transitions to an appropriate security
context for the user after authentication already. 

- On "Management of users and roles in flat file", Fedora already
supports local user definitions (and thus user-role authorizations, but
not the introduction of entirely new roles or modification of an
existing role) via flat file that are added to the policy prior to
loading, but the ongoing libsemanage and libsepol work will provide a
more complete interface for managing policy, and other work is creating
a separate mapping to let you authorize a particular Linux user for a
particular SELinux role set (via the indirection of a SELinux user) and
range without needing to touch policy at all. 

- On "Self tests", when I posted a RFC on "Checking the loaded policy
against a policy on disk" on the selinux list, there seemed to be
significant doubt about a) the practical usefulness of such a feature,
b) whether it is truly "required" or just a "nice to have", and c)
whether it even made sense in the absence of similar measures for
checking the integrity of rest of the kernel.  Hence, I haven't pursued
that further so far.

- Also on "Self tests", I have to wonder if the LTP is itself a
hindrance to getting people to contribute to the SELinux tests.  My own
experience has been that it is much more painful to build and run the
selinux tests through that test harness than through our original simple
perl Test-based one, as well as more painful to track down the source of
any failures when using it.

-- 
Stephen Smalley
National Security Agency