[redhat-lspp] lspp 12 kernel released

[Darrel Goeddel]

Stephen Smalley wrote:
> This has been discussed on selinux list multiple times (including just
> yesterday again, but also last Friday and back in Nov 2005), and TCS has
> twice posted modified initscripts to restorecon /dev/pts at boot to
> selinux list (back in Nov 2005 and again yesterday) since that is their
> current workaround.  Anyone here reading selinux list?
> 
> The issue is that devpts is a fs_use_trans filesystem, which means that
> it is labeled by the kernel based on computing "transition SIDs" from
> the SID of the creating task and the SID of the superblock.  Since
> devpts is kern-mounted during kernel initialization, the kernel SID is
> used as the creating task SID, and the (hardcoded) MLS logic is to
> inherit the MLS label from the creating task.  Since the kernel SID is
> associated with SystemHigh in the MLS policy, this makes the devpts root
> SystemHigh as well.  Unfortunately, the MLS engine does not have an
> equivalent to type_transition rules for files (it only has range
> transitions for processes), so we can't just define a transition rule in
> policy to make devpts pick up the desired MLS level.
> 
> Alternatives are:
> - restorecon /dev/pts from rc.sysinit; ugly but functional and avoids
> any need for kernel changes (which always take time to upstream, so
> you're looking at 2.6.17 at the earliest),

I think we need to do this for now.  Is that feasible?

> - re-introduce some kind of initial SID for the devpts root so that it
> can be assigned an explicit context rather than following the general
> transition logic; ugly and requires care about compatibility,
> - extend range_transition or add level_transition rules to policy and
> kernel for object classes, and define one for this purpose; likely the
> best long term solution, but not really viable in the short term I
> suspect.

This looks like the best approach.  It offers the most flexibility and
it is relatively easy to implement, but it will requires a binary format
change.

So... I agree with Stephen - initscript tweak for now, look at a policy
change for the future.

My suggestion for the policy change is to generalize the format of
range_transition from:

range_transition <process type> <executable type> <resulting range>

to:

range_transition <source type> <target type>:<object class> <resulting range>

The meaning of <source type> and <target type> would parallel the
meanings in the type_transition rules (i.e. process domain and executable
type for the object class process).  We could interpret the absence of
the ":<object class>" portion to be ":process" for backwards
compatibility with policy source if desired.

-- 

Darrel