Re: why label /dev/hugepages directory hugetlbfs_t?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/12/2010 03:45 PM, Dominick Grift wrote:
>  On Tue, Oct 12, 2010 at 11:54:42AM -0400, Daniel J Walsh wrote:
>  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
>  
>  
>  
> >
> > 
- --
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Yes that will work until you mount on top of /dev/hugepages and then if
you run restorecon -R -n -v /dev it will report that /dev/hugepages is
incorrectly labeled hugetlbfs_t.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAky0vDEACgkQrlYvE4MpobNjtACeJhkIRKXrAE8zBmx2AKSK7GZP
> 4B8AnA3BRamRHzzxYnSV8Y9rvc2wmCS7
> =moFn
> -----END PGP SIGNATURE-----