From: dac.override@gmail.com (Dominick Grift)
Date: Tue, 26 Aug 2014 16:53:00 +0200
Subject: [refpolicy] [PATCH 4/7] Add attribute file_type to pseudo
 filesystem types
In-Reply-To: <53FC7B94.3000001@tresys.com>
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>
Message-ID: <20140826145258.GA1464@e145.network2>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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).
> 

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

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

-- 
http://subkeys.pgp.net:11371/pks/lookup?search=0x02DFF788&op=index
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140826/072a215d/attachment.bin