From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 12 Sep 2014 14:14:19 -0400
Subject: [refpolicy] [PATCH 4/7] Add attribute file_type to pseudo
 filesystem types
In-Reply-To: <5400FE18.4040502@m4x.org>
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>
	<5400FE18.4040502@m4x.org>
Message-ID: <541337FB.9050408@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 8/29/2014 6:26 PM, Nicolas Iooss wrote:
> Le 26/08/2014 16:53, Dominick Grift a ?crit :
>> 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
>>
> 
> Tonight I read the output of "dmesg" and found this (which was not in
> audit.log):
> 
>     # dmesg |grep configfs
>     [    2.328208] SELinux: initialized (dev configfs, type configfs),
>     uses genfs_contexts
>     [    2.328258] audit: type=1400 audit(1409327503.834:3): avc:
>     denied  { write } for  pid=166 comm="mount" name="/" dev="configfs"
>     ino=1633 scontext=system_u:system_r:mount_t
>     tcontext=system_u:object_r:configfs_t tclass=dir permissive=1
> 
>     # ls -diZ /sys/kernel/config
>     1633 system_u:object_r:configfs_t /sys/kernel/config
> 
> However the real mountpoint directory is still sysfs_t:
> 
>     # mkdir /sys2
>     # mount --bind /sys /sys2
>     # ls -idZ /sys2/kernel/config /sys/kernel/config
>     10884    system_u:object_r:sysfs_t /sys2/kernel/config
>      1633 system_u:object_r:configfs_t /sys/kernel/config
> 
> Moreover /sys/kernel/config is almost empty and is not used for
> sub-mountpoints:
> 
>     # find /sys/kernel/config -exec ls -idZ {} \;
>     1633 system_u:object_r:configfs_t /sys/kernel/config
>     374658 system_u:object_r:configfs_t /sys/kernel/config/netconsole
> 
> So I don't understand why configfs_t would be "mountpoint", even if the
> "write symptom" is here.
> 
> 
> Finally, my policy (which is refpolicy + approx. 100 patches) contains:
> 
>     # sesearch --dontaudit -s mount_t -c dir -p write
>     Found 6 semantic av rules:
>        dontaudit mount_t devpts_t : dir { ioctl read write create
>     getattr setattr lock unlink link rename add_name remove_name
>     reparent search rmdir open } ;
>        dontaudit mount_t proc_t : dir write ;
>        dontaudit mount_t sysfs_t : dir { write getattr search open } ;
>        dontaudit mount_t tmpfs_t : dir write ;
>        dontaudit mount_t debugfs_t : dir write ;
>        dontaudit mount_t mountpoint : dir { write setattr } ;
> 
> The penultimate line is quite surprising.  It comes from this line in
> the refpolicy [1]:
> 
>     kernel_dontaudit_write_debugfs_dirs(mount_t)
> 
> ... which leads to commit a861c7c6fd90 ("dontaudit mount writes to newly
> mounted filesystems") [2].
> 
> Is it acceptable to create kernel_dontaudit_write_configfs_dirs
> interface and to use it for mount_t?

That would be fine.  What might make sense instead is make a pseudo
filesystem attribute and dontaudit mount_t dir:write on it.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com