why label /dev/hugepages directory hugetlbfs_t?

[Dominick Grift]

On Tue, Oct 12, 2010 at 11:54:42AM -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/12/2010 11:34 AM, Eric Paris wrote:
> > On Tue, 2010-10-12 at 11:01 -0400, Daniel J Walsh wrote:
> >> On 10/09/2010 11:30 AM, Dominick Grift wrote:
> >>> On Sat, Oct 09, 2010 at 09:14:25AM -0400, Eric Paris wrote:
> >>>> On Sat, 2010-10-09 at 11:43 +0200, Dominick Grift wrote:
> >>>>> Why is /dev/hugepages specified to be labeled hugetlbfs_t? Any
> >>>>> particular reason for this? 
> >>>>>
> >>>>> In my branch i labelled it device_t like most directories in /dev.
> >>>>>
> >>>>> This makes it easier because udev does some magic
> >>>>> in /lib/udev/devices(hugetables) which causes all kinds of extra
> >>>>> denials if i label the hugepages dir hugetlbfs_t.
> >>>>>
> >>>>> For example hugetlbfs_t must associate to device_t etc. Much easier to
> >>>>> just label hugepages directories at both /dev/hugepage
> >>>>> and /lib/udev/devices/hugepages device_t.
> >>>>>
> >>>>> Also i noticed that /sys/fs/cgroup is specified to be labeled
> >>>>> cgroup_t, but i think the kernel creates that directory with type
> >>>>> sysfs_t. So that would mean that it needs to be restored at each
> >>>>> boot-up.
> >>>>
> >>>> /dev/hugepages and (I think) /sys/fs/cgroup are filesystem mount points
> >>>> not actually files in the devfs or sysfs filesystem.  So the labels are
> >>>> picked probably picked up from the filesystem labeling rules at mount
> >>>> time rather than from a later restorecon.
> >>>
> >>> In my branch i have the directory /dev/hugepages set to device_t and this location is labelled properly (udev or dracut did it?)
> >>> Unlike /sys/fs/cgroup directory which is set to cgroup_t but this location is not labelled properly (sysfs_t instead of specified cgroup_t)
> >>>
> >>>>
> >>>> As to whether we need or want such labels on hugetlbfs and cgroupfs I'll
> >>>> let you and Dan argue about   :)
> > 
> >> I think the problem is running tools like restorecon on /dev to check
> >> labels. ends up generating errors when hugetlbfs and cgroupfs are
> >> mounted.  I guess we could change the label to <<none>>
> >>
> >> /dev/shm has the same problem.
> >>
> >> matchpathcon  /dev/shm
> >> /dev/shm	system_u:object_r:tmpfs_t:s0
> > 
> > But isn't /dev/shm just a normal tmpfs, not a special FS like cgroupfs
> > or hugepagefs?  I'm not saying the <<none>> isn't the right answer for
> > things under /dev/shm/ but it's not exactly the same problem....
> > 
> > -Eric
> > 
> 
> Not sure I see the difference.  We are talking about directories on
> special file systems like /dev and /sys that have files systems mounted
> on them.
> 
> tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
> 
> This shows that a tmpfs file system is mounted on /dev/shm.  I could
> leave /dev/shm as labeled device_t, but we label it tmpfs_t so that
> tools looking at /dev/ will not report a labeling problem.  To me this
> looks like the same thing we are doing with /dev/hugepages

i have:

# ls -alZ /dev | grep huge
drwxr-xr-x. root   root    system_u:object_r:device_t:s0    hugepages

# semanage fcontext -l | grep hugepages
/dev/hugepages                                     directory          system_u:object_r:device_t:s0 
/dev/hugepages/.*                                  all files          <<None>>
/lib/udev/devices/hugepages                        directory          system_u:object_r:device_t:s0 
/lib/udev/devices/hugepages/.*                     all files          <<None>>

It appears that this way i dont have to associate hugetblfs_t to device_t
However i am not sure because directory /dev/hugepages is empty here.

But for me so far this works best because i run kernel confined and udev does all kinds of crazy stuff early in the boot process and this seems to work clean for me so far

> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAky0hMEACgkQrlYvE4MpobNcxQCgzuRQTtZN8KnU3QkO86J2gF1y
> 2YkAoNDgF0yMxm7ndjHlLEG0WZT3wPJh
> =AmvQ
> -----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20101012/b2b78f46/attachment.bin