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
Yes, I agree we should just do the initsctript workaround for now.
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.
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.
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.