[Clip] CLIP dependencies

[Brandon Whalen]

On 3/13/09 8:34 AM, "Stephen Smalley" <sds at tycho.nsa.gov> wrote:

> Hi,
> 
> Can someone describe briefly what aspects of SELinux are actually
> required for CLIP?  In particular, I'm interested in:
> - the set of kernel security features needed by CLIP (e.g. I see
> reference to SECMARK in the Getting Started guide but it isn't clear
> why),
We backported SECMARK to RHEL 5 because we had a lot of users of CLIP want
to be able to apply labels to their networks at install time. The old
network controls were to rigid and required us to know the network topology
at policy creation time, which was nearly impossible, or to decrease the
amount of network separation we provided to ensure functionality.

I am not aware of anyone using labeled IPSec on a CLIP based system but it
is something that we rely on to meet requirements about reliably
transferring labels across systems and we will need this to have continued
support.

We have customers who are interested in placing SELinux systems into
environments using CIPSO to pass around labels on the network. While there
are translation issues across operating systems we would like to see
continued support for netlabel to allow us to have the basic functionality
and to see work done to allow us to more easily translate labels between
SELinux and other OS's such as Solaris.

We have had requests from customers to support Solaris like functionality
such as common lowest level, or common upper level for a set of users. This
kind of functionality can be done in userland, but to have the support as
part of the SELinux API would be ideal and help with transitioning of
Solaris developers to SELinux systems.

> - the set of policy features needed by the CLIP policy (e.g. conditional
> policy?  MLS-enabled policy?).
> 
We currently have to support MLS policies because the RHEL 5 series kernel
will not let us load a non MLS policy. Even if that were not the case we
have existing customers that are currently using the MLS portions of the
policy. We have downstream customers that make heavy use of booleans and
conditional policy to change the systems state at runtime.

We would like to see is more fined grain access control on the pieces of the
policy. Having a single application like semanage to control the majority of
the SELinux subsystem is nice for the majority of SELinux users but that
kind of coarse grained access control does not fit well when applied to
national security systems and other downstream users of CLIP.

I'm sure there are things I'm forgetting and others might have on their mind
that I'm not thinking of. Gunnar, I'm sure you've got a list in your head as
well. For now I think this is a good starting point for what we need from
upstream and if I come up with more I'll send out updates to keep you
informed.
 

> Thanks.

Brandon