On Thu, 2010-04-29 at 10:15 -0400, Stephen Smalley wrote: > On Thu, 2010-04-29 at 09:57 -0400, Christopher J. PeBenito wrote: > > On Thu, 2010-04-29 at 09:02 -0400, Stephen Smalley wrote: > > > On Thu, 2010-04-29 at 10:14 +0400, selinux@xxxxxxxx wrote: > > > > Yes, ofcourse, it is labelled. Plus, my little "fix" by allowing kernel_t > > > > access to tmpfs_t allowed the system to properly boot and function in > > > > enforced mode and transition to system services and to getty_t, etc, etc. > > > > Can that happen with labelling problems? > > > > And ofcourse, getty should never be in kernel_t. > > > > > > Ok, I understand your problem now. > > > devtmpfs internally switches to the initial task's credentials when > > > performing internal operations like creating new device nodes when they > > > are requested by the driver. Otherwise we'd have to allow whatever > > > happened to be the currently running process (e.g. getty_t) to perform > > > those operations, whereas they aren't originating from that process at > > > all and we don't want to permit the process to perform that action on > > > its own. That's why it shows up as kernel_t. In the Fedora default > > > targeted policy, kernel_t is unconfined and everything just works. If > > > we don't already have explicit allow rules permitting kernel_t to create > > > these nodes in whatever default type we assign to devtmpfs, then that's > > > a policy bug. > > > > To make sure I understand correctly since I'm not versed in devtmpfs > > yet, kernel_t should be able to create device nodes, directories and > > symlinks in /dev? Does it create them with the right context, or does > > it rely on udev to come by and relabel them? > > Based on the code, it appears to create and delete directories and > device nodes, no symlinks. It cannot create them in the right context > since the kernel knows nothing of file_contexts, so it just creates them > in the default context, Ah yes, I don't know what I was thinking. > leaving it to userspace (restorecon or udev) to > assign the correct context. It would be better if that were device_t > rather than tmpfs_t for obvious reasons. I suppose an interim solution would be to have a kernel_t type transition on tmpfs_t to device_t for chr_file, blk_file, and dir, until we can fix up the policy so devtmpfs can be device_t. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
