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

[Chad Hanson]

> 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.
>

We are in the process of updating our current MLS policy to rawhide sources.
We hope this should be done soon. We can provide a patch to the MLS policy
that Dan Walsh is maintaining currently and work out any kinks so we can get
this into rawhide.
 
> 
> - 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.
> 

We do have our own MITRE translation library. I would think we should either
extend the current libsetrans to support a generic MLS translator based on
whether the config is MCS or MLS or just create a new libsetrans. I don;t
know which is the best approach here.

> - 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. 
> 

We do have an xinetd patch I can post. I need to check on openssh.

-Chad