Looks like its a normal tmpfs <snip> tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0 <snip>
I don't see anything else overlaying /dev mount point. I currently dont have anything attempting to access it outside of kernel domain... One of the best features of SELinux is finding issues in various things, like DAC perms. Perhaps, I can get kdevtmpfs dropped, I see no use for it here. Thanks, Bill On Wed, Aug 26, 2015 at 9:25 AM, Stephen Smalley <[email protected]> wrote: > On 08/26/2015 12:10 PM, Nick Kralevich wrote: > > > > > > On Wed, Aug 26, 2015 at 6:47 AM, Stephen Smalley <[email protected] > > <mailto:[email protected]>> wrote: > > > > With devtmpfs, the kernel itself automatically populates and > maintains a > > device node tree. The claim is that this provides you with a working > > /dev tree before udev comes up, and that you can even dispense with > > running udev entirely on simple systems (e.g. embedded). However, it > > seems like everyone continues to run udev on top of devtmpfs in Linux > > distributions. > > > > The problem of course is that the kernel has no clue how to label the > > device nodes, so it is still necessary to have udev or ueventd handle > > that. And with the kernel creation of the device nodes, we then > have a > > race condition where the device node briefly exists in the wrong, > most > > likely inaccessible label. > > > > > > Do you know how other standard DAC permissions are configured by the > > kernel? The kernel must have some knowledge of how to set the > > UID/GID/perms/etc... > > As per drivers/base/devtmpfs.c, they default to root ownership and mode > 0600 unless overridden by the driver. Otherwise it is up to > udev/ueventd to fix up the permissions afterward. > > The situation for SELinux contexts is similar (they will default to > device type until fixed by udev/ueventd), but we are more likely to run > afoul of race conditions because we don't allow all root processes to > access all device nodes. So we can end up denying access that would be > allowed once the label is correctly set by udev/ueventd. > > Fedora currently avoids this via lots of name-based type transitions on > (kernel, device, chr_file|blk_file) but that is decidedly suboptimal. > > We could certainly add devtmpfs to the list of filesystems for which we > support per-file genfs_contexts-based labeling, and then add /dev > entries there (prefix match, not regex match). > > But I guess the question is why use devtmpfs at all if you are going to > run udev/ueventd anyway. What's the practical benefit? > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [email protected]. > -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
