From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Wed, 27 Aug 2014 23:51:23 +0200
Subject: [refpolicy] [PATCH 4/7] Add attribute file_type to pseudo
 filesystem types
In-Reply-To: <20140826145258.GA1464@e145.network2>
References: <1408793751-11289-1-git-send-email-nicolas.iooss@m4x.org>
	<1408793751-11289-5-git-send-email-nicolas.iooss@m4x.org>
	<53FC7B94.3000001@tresys.com> <20140826145258.GA1464@e145.network2>
Message-ID: <53FE52DB.8000605@m4x.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

2014-08-26 16:53 GMT+02:00 Dominick Grift:
> On Tue, Aug 26, 2014 at 08:20:36AM -0400, Christopher J. PeBenito wrote:
>> On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
>>
>> I don't think debugfs_t is a good example.  Looking at the file
>> contexts, I don't see why it needs to be a mount point.  I also don't
>> think that these pseudo filesystems should be file types either since
>> they aren't regular files.  It seems like the best choice would be to
>> use fs_getattr_all_dirs(collectd_t).
>>
OK.  I'll do that and send a patch once I've tested it.

I used debugfs_t as an example because its default mountpoint is in the
same directory as the one of configfs_t (/sys/kernel/debug and
/sys/kernel/config) and these two file systems use files and directories
to query/set the kernel configuration.  So to my mind, if configfs_t
should not have file_type, the same arguments apply to debugfs_t.

I don't know why debugfs_t needs to have "mountpoint" attribute and
whether it would be possible (or even meaningful) to give mountpoint to
a type without giving file_type, so I won't send a patch to change the
current debugfs_t attributes.

Nevertheless I added files_type to much more filesystems than required
because I thought "file_type" was a kind of generic attribute for things
with a file API, as opposed to "domain" (processes) and "userdomain"
(users).  It seems I was wrong.


> In my experience, a way to see if something should be classified mountpoint (or whether some directory should maybe not be labeled with a filesystem type)
> is look for AVC denials like this:
>
> avc:  denied  { write } for  pid=674 comm="mount" name="/" dev="debugfs" ino=1 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:debugfs_t tclass=dir permissive=0
>
> The mount command checks mountpoint file directories for write access

OK.  Just out of curiosity, is this write access expected or a kind of
bug that is silently denied by the refpolicy, which contains
files_dontaudit_write_all_mountpoints(mount_t) in system/mount.te?

>
> it can be a tough call. I had this for example with cgroupfs. In fedora, systemd does some voodoo with tmpfs and cgroupfs
> the result was that /sys/fs/cgroup dir was labeled type cgroup_t but the links that were created early on in /sys/fs/cgroup remained type tmpfs_t
>
> The inconsistency aggitated me and so i decided to just remove the fc spec for /sys/fs/cgroup. This caused /sys/fs/cgroup to end up with
> tmpfs_t just like the links in there, which no one except systemd use anyways
>
> It allowed me to disassociate the file_type and mountpoint_type attributes with cgroup_t (since now mount, mounts on tmpfs_t dirs instead)
>
> This hack would not be upstreamable since this is systemd specific but it does demonstrate some of the reasoning for some of my decisions
> about whether to associate something ith mountpoint_type or not

Thanks for your explanation.

Nicolas