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: http://www.redhat.com/archives/fedora-selinux-list/2006-April/thread.html#00200
> 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 checks today.
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.