From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Sat, 30 Aug 2014 00:26:32 +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: <5400FE18.4040502@m4x.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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?

Thanks,

Nicolas

[1]
https://github.com/TresysTechnology/refpolicy/blob/1743984bafd19d093d29923ce7717a15f2b2a965/policy/modules/system/mount.te#L64
[2]
https://github.com/TresysTechnology/refpolicy/commit/a861c7c6fd90f0272dd69e1395f766cbce5057f0