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 <sds@xxxxxxxxxxxxx> wrote:
On 08/26/2015 12:10 PM, Nick Kralevich wrote:
>
>
> On Wed, Aug 26, 2015 at 6:47 AM, Stephen Smalley <sds@xxxxxxxxxxxxx
> <mailto:sds@xxxxxxxxxxxxx>> 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
Seandroid-list@xxxxxxxxxxxxx
To unsubscribe, send email to Seandroid-list-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Seandroid-list-request@xxxxxxxxxxxxx.
Respectfully,
William C Roberts
William C Roberts
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
