Set of small patches

On ArchLinux the directory name of Network Manager in /usr/lib is written in lowercase but not the files in /usr/bin, /var/lib, etc.

While at it, remove a useless backslash before a minus character.

---
 policy/modules/kernel/corecommands.fc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

policy/modules/kernel/corecommands.fc +0 -0

index 1384699f4658..c860d81b7f37 100644

On Debian, /var/spool/postfix/dev contains log, urandom and random in the same types as the files in /dev.

---
 policy/modules/kernel/devices.fc | 4 ++++
 policy/modules/system/logging.fc | 1 +
 2 files changed, 5 insertions(+)

policy/modules/kernel/devices.fc +4 -0

index d6ebfcd4e570..2356cf0d4dc8 100644
@@ -201,6 +201,10 @@ ifdef(`distro_debian',`
 /sys(/.*)?			gen_context(system_u:object_r:sysfs_t,s0)
 /sys/devices/system/cpu/online	--	gen_context(system_u:object_r:cpu_online_t,s0)
 
+/var/spool/postfix/dev		-d	gen_context(system_u:object_r:device_t,s0)
+/var/spool/postfix/dev/random	-c	gen_context(system_u:object_r:random_device_t,s0)
+/var/spool/postfix/dev/urandom	-c	gen_context(system_u:object_r:urandom_device_t,s0)
+
 ifdef(`distro_redhat',`
 # originally from named.fc
 /var/named/chroot/dev	-d	gen_context(system_u:object_r:device_t,s0)

policy/modules/system/logging.fc +1 -0

index 428e43f117e5..374fb53ee0fd 100644
@@ -72,6 +72,7 @@ ifdef(`distro_redhat',`
 /var/spool/bacula/log(/.*)? 	gen_context(system_u:object_r:var_log_t,s0)
 /var/spool/postfix/pid	-d	gen_context(system_u:object_r:var_run_t,s0)
 /var/spool/plymouth/boot\.log	gen_context(system_u:object_r:var_log_t,mls_systemhigh)
+/var/spool/postfix/dev/log -s	gen_context(system_u:object_r:devlog_t,s0)
 /var/spool/rsyslog(/.*)? 	gen_context(system_u:object_r:var_log_t,s0)
 
 /var/tinydns/log/main(/.*)?	gen_context(system_u:object_r:var_log_t,s0)

Quoted 2 lines

On Debian, /var/spool/postfix/dev contains log, urandom and random in the same types as the files in /dev.

It might make more sense for Debian to have a path substitution, rather than duplicating file contexts. I'm guessing this is Postfix chrooting into /var/spool/postfix, so /var/spool/postfix/dev is the chroot's /dev?

---
 policy/modules/kernel/filesystem.if | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

policy/modules/kernel/filesystem.if +0 -0

index d24ae64f72b0..74d7b7321257 100644

Files in /sys/kernel/config are labeled configfs_t so this type needs attribute "file_type". Without this attribute, these denials happen when using collectd with "df" plugin (this plugin enumerate mountpoints and collect disk usage stats):

avc: denied { getattr } for pid=872 comm="collectd" path="/sys/kernel/config" dev="configfs" ino=10234 scontext=system_u:system_r:collectd_t tcontext=system_u:object_r:configfs_t tclass=dir

As collectd.te already contains files_getattr_all_dirs(collectd_t), adding file_type to configfs_t is enough to allow this access.

Moreover, similar filesystems such as debugfs_t already has file_type:

    $ seinfo -xtdebugfs_t
       debugfs_t
          file_type
          filesystem_type
          non_security_file_type
          mountpoint
          non_auth_file_type
    $ seinfo -xtconfigfs_t
       configfs_t
          filesystem_type

This is because kernel.te contains files_mountpoint(debugfs_t), which uses files_type(debugfs_t).

This patch adds files_type() to every pseudo filesystem type that doesn't have file_type yet.

---
 policy/modules/kernel/filesystem.te | 11 +++++++++++
 policy/modules/kernel/kernel.te     |  1 +
 2 files changed, 12 insertions(+)

policy/modules/kernel/filesystem.te +11 -0

index cf04fb76dc66..083756999432 100644
@@ -58,6 +58,7 @@ genfscon anon_inodefs / gen_context(system_u:object_r:anon_inodefs_t,s0)
 
 type bdev_t;
 fs_type(bdev_t)
+files_type(bdev_t)
 genfscon bdev / gen_context(system_u:object_r:bdev_t,s0)
 
 type binfmt_misc_fs_t;

@@ -78,10 +79,12 @@ genfscon cgroup / gen_context(system_u:object_r:cgroup_t,s0)
 
 type configfs_t;
 fs_type(configfs_t)
+files_type(configfs_t)
 genfscon configfs / gen_context(system_u:object_r:configfs_t,s0)
 
 type cpusetfs_t;
 fs_type(cpusetfs_t)
+files_type(cpusetfs_t)
 allow cpusetfs_t self:filesystem associate;
 genfscon cpuset / gen_context(system_u:object_r:cpusetfs_t,s0)
 

@@ -92,6 +95,7 @@ genfscon ecryptfs / gen_context(system_u:object_r:ecryptfs_t,s0)
 
 type futexfs_t;
 fs_type(futexfs_t)
+files_type(futexfs_t)
 genfscon futexfs / gen_context(system_u:object_r:futexfs_t,s0)
 
 type hugetlbfs_t;

@@ -102,29 +106,35 @@ fs_use_trans hugetlbfs gen_context(system_u:object_r:hugetlbfs_t,s0);
 
 type ibmasmfs_t;
 fs_type(ibmasmfs_t)
+files_type(ibmasmfs_t)
 allow ibmasmfs_t self:filesystem associate;
 genfscon ibmasmfs / gen_context(system_u:object_r:ibmasmfs_t,s0)
 
 type infinibandeventfs_t;
 fs_type(infinibandeventfs_t)
+files_type(infinibandeventfs_t)
 allow infinibandeventfs_t self:filesystem associate;
 genfscon infinibandeventfs / gen_context(system_u:object_r:infinibandeventfs_t,s0)
 
 type inotifyfs_t;
 fs_type(inotifyfs_t)
+files_type(inotifyfs_t)
 genfscon inotifyfs / gen_context(system_u:object_r:inotifyfs_t,s0)
 
 type mvfs_t;
 fs_noxattr_type(mvfs_t)
+files_type(mvfs_t)
 allow mvfs_t self:filesystem associate;
 genfscon mvfs / gen_context(system_u:object_r:mvfs_t,s0)
 
 type nfsd_fs_t;
 fs_type(nfsd_fs_t)
+files_type(nfsd_fs_t)
 genfscon nfsd / gen_context(system_u:object_r:nfsd_fs_t,s0)
 
 type oprofilefs_t;
 fs_type(oprofilefs_t)
+files_type(oprofilefs_t)
 genfscon oprofilefs / gen_context(system_u:object_r:oprofilefs_t,s0)
 
 type pstore_t;

@@ -140,6 +150,7 @@ genfscon ramfs / gen_context(system_u:object_r:ramfs_t,s0)
 
 type romfs_t;
 fs_type(romfs_t)
+files_type(romfs_t)
 genfscon romfs / gen_context(system_u:object_r:romfs_t,s0)
 genfscon cramfs / gen_context(system_u:object_r:romfs_t,s0)
 

policy/modules/kernel/kernel.te +1 -0

index 3fc6a56d41f0..f6cd41b70135 100644
@@ -66,6 +66,7 @@ genfscon debugfs / gen_context(system_u:object_r:debugfs_t,s0)
 #
 
 type kvmfs_t;
+files_type(kvmfs_t)
 fs_type(kvmfs_t)
 genfscon kvmfs / gen_context(system_u:object_r:kvmfs_t,s0)
 

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

Quoted 8 lines · Nicolas Iooss

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

Quoted 3 lines

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?

Quoted 8 lines · Nicolas Iooss

Quoted 3 lines

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?

In my view it should probably be:

dontaudit $1 mountpoint:dir audit_access

I have an interface called: files_audit_access_all_mountpoints()

... Or something along those lines

Quoted 8 lines · Nicolas Iooss

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

Le 26/08/2014 16:53, Dominick Grift a ?crit :

Quoted 10 lines · Christopher J. PeBenito

Quoted 8 lines · Nicolas Iooss

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

Quoted 7 lines

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?

---
 policy/support/obj_perm_sets.spt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

policy/support/obj_perm_sets.spt +0 -0

index 6e9131723cf4..5e8718a8be67 100644

Quoted 4 lines

---
 policy/support/obj_perm_sets.spt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

policy/support/obj_perm_sets.spt define(`devfile_class_set', `{ chr_file blk_file }') · line 31

Quoted 11 lines

policy/support/obj_perm_sets.spt +1 -2

index 6e9131723cf4..5e8718a8be67 100644
@@ -28,8 +28,7 @@ define(`devfile_class_set', `{ chr_file blk_file }')
 #
 # All socket classes.
 #
-define(`socket_class_set', `{ tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket }')
-
+define(`socket_class_set', `{ socket dccp_socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket }')

I don't think we want to add socket to this set. We need to be able to detect when there is generic socket class usage, as that means we need a kernel change and a corresponding new object class.

2014-08-25 17:07 GMT+02:00 Christopher J. PeBenito:

Quoted 12 lines · Nicolas Iooss

policy/support/obj_perm_sets.spt define(`devfile_class_set', `{ chr_file blk_file }') · line 31

Quoted 7 lines

policy/support/obj_perm_sets.spt +1 -2

@@ -28,8 +28,7 @@ define(`devfile_class_set', `{ chr_file blk_file }')
 #
 # All socket classes.
 #
-define(`socket_class_set', `{ tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket }')
-
+define(`socket_class_set', `{ socket dccp_socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket unix_stream_socket unix_dgram_socket appletalk_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket netlink_kobject_uevent_socket tun_socket }')

I don't think we want to add socket to this set. We need to be able to detect when there is generic socket class usage, as that means we need a kernel change and a corresponding new object class.

I agree with this point of view, if "socket" class means "generic socket which is never used in practice" (and which defines access vectors common to all socket classes, as stated on the SELinux wiki [1]).

Now that you said that "socket" should be used to detect new socket class (if I understood correctly), there is something I no longer understand in the current policy. Why does contrib/mozilla.te contains this? [5]

    allow mozilla_t self:socket create_socket_perms;

A quick "grep :socket -r policy" shows other domains allowed to use this kind of socket. Do you know where I could find a good documentation about the socket class to understand why these allow rules are needed?

manage_lnk_file_perms permission is expected to be larger than write_lnk_file_perms and therefore include ioctl and lock.

---
 policy/support/obj_perm_sets.spt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

policy/support/obj_perm_sets.spt +0 -0

index 5e8718a8be67..cefc35f7b547 100644

Such directories are used by systemd as private mountpoints for services.

---
 policy/modules/kernel/files.fc | 7 +++++++
 1 file changed, 7 insertions(+)

policy/modules/kernel/files.fc +4 -0

index b876c48adb12..fc765e7b38a7 100644
@@ -191,6 +191,10 @@ ifdef(`distro_debian',`
 /tmp/lost\+found	-d	gen_context(system_u:object_r:lost_found_t,mls_systemhigh)
 /tmp/lost\+found/.*		<<none>>
 
+/tmp/systemd-private-[^/]+	-d	gen_context(system_u:object_r:tmp_t,s0-mls_systemhigh)
+/tmp/systemd-private-[^/]+/tmp	-d	gen_context(system_u:object_r:tmp_t,s0-mls_systemhigh)
+/tmp/systemd-private-[^/]+/tmp/.*	<<none>>
+
 #
 # /usr
 #