From mail from SDS:
In the short term, I think you are just blocking on a policy change to
allow you to fix the root inode label via restorecon after mounting the
fs with the fscontext= option. In the long term, I think we want some
changes/extensions to context mount options and their handling in the
kernel to allow things like:
- rootcontext= option for specifying root inode label separate from
fscontext label for fs_use_trans filesystems (like tmpfs), and
- combined use of context= and fscontext= options (requested separately
by Russell Coker).
And then separately there are issues like the devpts root and its MLS
label, which requires range_transition support on objects.
It's a blocker at least for the short term fix, and that seems like something
better suited to base policy than a module.
For reference, the thread this came from:
> My best vague and uneducated guess is
> rootcontext=context of the root inode on the fs to be mounted.
Correct. This option doesn't exist yet, unlike the others.
> fscontext=the type of filesystem it is. in this case tells it is to
> label it tmpfs
Security context of the superblock object. Does not affect labeling
behavior for inodes. Currently incompatible with context= option (since
it also currently sets the superblock context, and then inherits from
it), but this could be changed.
> context=the context of every file on that fs.
Correct (and the superblock object too presently). This alters the
labeling behavior of the fs to what is called "mountpoint labeling",
where the specified context takes precedence over any xattr value or any
other behavior specified by fs_use. The context is applied to the
superblock object, and then inherited by all inodes from it.
There is also:
defcontext= default file context to apply to files that lack an xattr
value when using xattrs as the labeling behavior.
> would I ever want all 3 together?
Possibly; they don't necessarily have to conflict.
context=A fscontext=B rootcontext=C would mean "label the superblock B,
the root directory inode C, and all other inodes A".
> And I'm still not to smart on the
> associate permission. Which of those 3 would affect associate? What
> was it that Russel wanted done with these things?
Anything that alters the superblock context affects associate checks
(which are between the file contexts and the superblock context, e.g. so
that policy can say that partition with type A can only hold data of
type A and partition with type B can only hold data of type B, or
replace types with levels or whatever).
Posted the nsa selinux list. on try 3 hopefully i fixed all the problems...
committed in 2.6.18 (but after rc1). Will post a follow up to correct security
Do you know what -gitX (and therefore what built kernel) has these fixes?
patch-2.6.18-rc1-git4.bz2 is where it first appears.
Seems to work for me with -2380.