Bug 185436 - Kernel needs to create /dev/pts with correct type/sensitivity for MLS
Summary: Kernel needs to create /dev/pts with correct type/sensitivity for MLS
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eric Paris
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On: 185497
Blocks: 181563 202597
TreeView+ depends on / blocked
 
Reported: 2006-03-14 19:58 UTC by Daniel Walsh
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-17 18:26:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Daniel Walsh 2006-03-14 19:58:49 UTC
Description of problem:

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

Comment 1 James Morris 2006-03-14 20:12:21 UTC
Yes, I agree we should just do the initsctript workaround for now.

Comment 2 Russell Coker 2006-03-15 09:02:35 UTC
I have filed bugzilla 185497 against initscripts to get restorecon run 
on /dev/pts.  Note that when we eventually get the kernel code changed to do 
this we have to go back and remove the restorecon from initscripts and also 
change policy to not permit devpts_t as a type for a tmpfs file system. 

Comment 4 Eric Paris 2006-08-22 18:20:22 UTC
The kernel portion of the patch set to solve this issue has been submitted
upstream and internally to Red Hat for inclusion in RHEL5.  This bug is now
being left open to track userspace and implementation of new fuctionality.

Comment 5 Dave Jones 2006-10-16 17:22:56 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.


Note You need to log in before you can comment on or make changes to this bug.