Re: kernel access to device comm is kdevtmpfs

[Stephen Smalley <sds@tycho.nsa.gov>]

On 08/26/2015 10:07 AM, Dominick Grift wrote:
> On Wed, Aug 26, 2015 at 09:47:31AM -0400, Stephen Smalley wrote:
> 
> <snip>
> 
> 
>> Fedora has tried to work around this by defining name-based type
>> transitions for the kernel domain on /dev to label the device nodes
>> correctly on creation.  However, name-based type transitions aren't well
>> suited to that purpose; they only support exact match (no prefix, glob,
>> or regex matching), they only match the last component, and they were
>> only intended to cover exceptional cases where regular type transitions
>> weren't sufficiently granular and one couldn't modify the creating
>> program to explicitly label the file based on file_contexts (so they
>> aren't designed to scale well).  Maybe we could use genfs_contexts
>> instead (i.e. add devtmpfs to the list of filesystems that have
>> SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
>> relative to the root of devtmpfs and label them that way).
> 
> This sounds like a good idea to me.

Unfortunately, I was wrong.  Merely setting SE_SBGENFS in sbsec->flags
for devtmpfs filesystems does NOT enable genfs_context-based labeling of
devtmpfs files, because devtmpfs is tmpfs-backed, and tmpfs, like ext4,
calls security_inode_init_security() upon new inode creation to
explicitly initialize the in-core inode security state and to obtain the
xattr name/value pair.  That's why type transitions work for devtmpfs
(and tmpfs).  Filesystems that use genfscon-based labeling (e.g. proc,
sysfs, debugfs, pstore) do not support userspace file creation and
therefore do not call that hook and their inode security state is
initialized upon security_d_instantiate(), at which point we have a
dentry and can therefore generate a path relative to the root.
So we can't do this as a one-liner patch; it would be more involved.
devtmpfs/tmpfs does ultimately call d_instantiate() ->
security_d_instantiate(), but at that point the inode security state is
already initialized in the usual way and we therefore don't do anything
further with it.  We would need to rework the way inode security
initialization works, and do it in a way that avoids weird side effects
(e.g. if the policy defines a type transition, as in current Fedora
policy, we don't want to override that with a genfscon-based lookup).