Dear list,
Here are small patches which add some file labels and fix some
inconsistencies in the policy.
Nicolas Iooss (7):
Label /usr/lib/networkmanager/ like /usr/lib/NetworkManager/
Label /var/spool/postfix/dev/ files
Fix typo in fs_getattr_all_fs description
Add attribute file_type to pseudo filesystem types
Add socket and dccp_socket to socket_class_set
Add ioctl and lock to manage_lnk_file_perms
Label (/var)?/tmp/systemd-private-.../tmp like /tmp
policy/modules/kernel/corecommands.fc | 3 ++-
policy/modules/kernel/devices.fc | 4 ++++
policy/modules/kernel/files.fc | 7 +++++++
policy/modules/kernel/filesystem.if | 2 +-
policy/modules/kernel/filesystem.te | 11 +++++++++++
policy/modules/kernel/kernel.te | 1 +
policy/modules/system/logging.fc | 1 +
policy/support/obj_perm_sets.spt | 5 ++---
8 files changed, 29 insertions(+), 5 deletions(-)
--
2.0.4
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(-)
diff --git a/policy/modules/kernel/corecommands.fc b/policy/modules/kernel/corecommands.fc
index 1384699f4658..c860d81b7f37 100644
--- a/policy/modules/kernel/corecommands.fc
+++ b/policy/modules/kernel/corecommands.fc
@@ -223,7 +223,8 @@ ifdef(`distro_gentoo',`
/usr/lib/misc/sftp-server -- gen_context(system_u:object_r:bin_t,s0)
/usr/lib/nagios/plugins(/.*)? gen_context(system_u:object_r:bin_t,s0)
/usr/lib/netsaint/plugins(/.*)? gen_context(system_u:object_r:bin_t,s0)
-/usr/lib/NetworkManager/nm\-.* -- gen_context(system_u:object_r:bin_t,s0)
+/usr/lib/NetworkManager/nm-.* -- gen_context(system_u:object_r:bin_t,s0)
+/usr/lib/networkmanager/nm-.* -- gen_context(system_u:object_r:bin_t,s0)
/usr/lib/news/bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
/usr/lib/nspluginwrapper/np.* gen_context(system_u:object_r:bin_t,s0)
/usr/lib/portage/bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
--
2.0.4
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(+)
diff --git a/policy/modules/kernel/devices.fc b/policy/modules/kernel/devices.fc
index d6ebfcd4e570..2356cf0d4dc8 100644
--- a/policy/modules/kernel/devices.fc
+++ b/policy/modules/kernel/devices.fc
@@ -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)
diff --git a/policy/modules/system/logging.fc b/policy/modules/system/logging.fc
index 428e43f117e5..374fb53ee0fd 100644
--- a/policy/modules/system/logging.fc
+++ b/policy/modules/system/logging.fc
@@ -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)
--
2.0.4
---
policy/modules/kernel/filesystem.if | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/policy/modules/kernel/filesystem.if b/policy/modules/kernel/filesystem.if
index d24ae64f72b0..74d7b7321257 100644
--- a/policy/modules/kernel/filesystem.if
+++ b/policy/modules/kernel/filesystem.if
@@ -4607,7 +4607,7 @@ interface(`fs_unmount_all_fs',`
## <desc>
## <p>
## Allow the specified domain to
-## et the attributes of all filesystems.
+## get the attributes of all filesystems.
## Example attributes:
## </p>
## <ul>
--
2.0.4
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(+)
diff --git a/policy/modules/kernel/filesystem.te b/policy/modules/kernel/filesystem.te
index cf04fb76dc66..083756999432 100644
--- a/policy/modules/kernel/filesystem.te
+++ b/policy/modules/kernel/filesystem.te
@@ -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)
diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
index 3fc6a56d41f0..f6cd41b70135 100644
--- a/policy/modules/kernel/kernel.te
+++ b/policy/modules/kernel/kernel.te
@@ -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)
--
2.0.4
---
policy/support/obj_perm_sets.spt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/policy/support/obj_perm_sets.spt b/policy/support/obj_perm_sets.spt
index 6e9131723cf4..5e8718a8be67 100644
--- a/policy/support/obj_perm_sets.spt
+++ b/policy/support/obj_perm_sets.spt
@@ -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 }')
#
# Datagram socket classes.
--
2.0.4
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(-)
diff --git a/policy/support/obj_perm_sets.spt b/policy/support/obj_perm_sets.spt
index 5e8718a8be67..cefc35f7b547 100644
--- a/policy/support/obj_perm_sets.spt
+++ b/policy/support/obj_perm_sets.spt
@@ -178,7 +178,7 @@ define(`rw_lnk_file_perms',`{ getattr read write lock ioctl }')
define(`create_lnk_file_perms',`{ create getattr }')
define(`rename_lnk_file_perms',`{ getattr rename }')
define(`delete_lnk_file_perms',`{ getattr unlink }')
-define(`manage_lnk_file_perms',`{ create read write getattr setattr link unlink rename }')
+define(`manage_lnk_file_perms',`{ create read write getattr setattr link unlink rename ioctl lock }')
define(`relabelfrom_lnk_file_perms',`{ getattr relabelfrom }')
define(`relabelto_lnk_file_perms',`{ getattr relabelto }')
define(`relabel_lnk_file_perms',`{ getattr relabelfrom relabelto }')
--
2.0.4
Such directories are used by systemd as private mountpoints for
services.
---
policy/modules/kernel/files.fc | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/policy/modules/kernel/files.fc b/policy/modules/kernel/files.fc
index b876c48adb12..fc765e7b38a7 100644
--- a/policy/modules/kernel/files.fc
+++ b/policy/modules/kernel/files.fc
@@ -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
#
@@ -265,6 +269,9 @@ ifndef(`distro_redhat',`
/var/tmp/.* <<none>>
/var/tmp/lost\+found -d gen_context(system_u:object_r:lost_found_t,mls_systemhigh)
/var/tmp/lost\+found/.* <<none>>
+/var/tmp/systemd-private-[^/]+ -d gen_context(system_u:object_r:tmp_t,s0-mls_systemhigh)
+/var/tmp/systemd-private-[^/]+/tmp -d gen_context(system_u:object_r:tmp_t,s0-mls_systemhigh)
+/var/tmp/systemd-private-[^/]+/tmp/.* <<none>>
/var/tmp/vi\.recover -d gen_context(system_u:object_r:tmp_t,s0)
ifdef(`distro_debian',`
--
2.0.4
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> 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/devices.fc | 4 ++++
> policy/modules/system/logging.fc | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/policy/modules/kernel/devices.fc b/policy/modules/kernel/devices.fc
> index d6ebfcd4e570..2356cf0d4dc8 100644
> --- a/policy/modules/kernel/devices.fc
> +++ b/policy/modules/kernel/devices.fc
> @@ -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)
> diff --git a/policy/modules/system/logging.fc b/policy/modules/system/logging.fc
> index 428e43f117e5..374fb53ee0fd 100644
> --- a/policy/modules/system/logging.fc
> +++ b/policy/modules/system/logging.fc
> @@ -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)
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> ---
> policy/support/obj_perm_sets.spt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/policy/support/obj_perm_sets.spt b/policy/support/obj_perm_sets.spt
> index 6e9131723cf4..5e8718a8be67 100644
> --- a/policy/support/obj_perm_sets.spt
> +++ b/policy/support/obj_perm_sets.spt
> @@ -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.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> 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.
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).
> ---
> policy/modules/kernel/filesystem.te | 11 +++++++++++
> policy/modules/kernel/kernel.te | 1 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/policy/modules/kernel/filesystem.te b/policy/modules/kernel/filesystem.te
> index cf04fb76dc66..083756999432 100644
> --- a/policy/modules/kernel/filesystem.te
> +++ b/policy/modules/kernel/filesystem.te
> @@ -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)
>
> diff --git a/policy/modules/kernel/kernel.te b/policy/modules/kernel/kernel.te
> index 3fc6a56d41f0..f6cd41b70135 100644
> --- a/policy/modules/kernel/kernel.te
> +++ b/policy/modules/kernel/kernel.te
> @@ -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)
>
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> 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(-)
>
> diff --git a/policy/modules/kernel/corecommands.fc b/policy/modules/kernel/corecommands.fc
> index 1384699f4658..c860d81b7f37 100644
> --- a/policy/modules/kernel/corecommands.fc
> +++ b/policy/modules/kernel/corecommands.fc
> @@ -223,7 +223,8 @@ ifdef(`distro_gentoo',`
> /usr/lib/misc/sftp-server -- gen_context(system_u:object_r:bin_t,s0)
> /usr/lib/nagios/plugins(/.*)? gen_context(system_u:object_r:bin_t,s0)
> /usr/lib/netsaint/plugins(/.*)? gen_context(system_u:object_r:bin_t,s0)
> -/usr/lib/NetworkManager/nm\-.* -- gen_context(system_u:object_r:bin_t,s0)
> +/usr/lib/NetworkManager/nm-.* -- gen_context(system_u:object_r:bin_t,s0)
> +/usr/lib/networkmanager/nm-.* -- gen_context(system_u:object_r:bin_t,s0)
> /usr/lib/news/bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
> /usr/lib/nspluginwrapper/np.* gen_context(system_u:object_r:bin_t,s0)
> /usr/lib/portage/bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
Merged.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> Such directories are used by systemd as private mountpoints for
> services.
> ---
> policy/modules/kernel/files.fc | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/policy/modules/kernel/files.fc b/policy/modules/kernel/files.fc
> index b876c48adb12..fc765e7b38a7 100644
> --- a/policy/modules/kernel/files.fc
> +++ b/policy/modules/kernel/files.fc
> @@ -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
> #
> @@ -265,6 +269,9 @@ ifndef(`distro_redhat',`
> /var/tmp/.* <<none>>
> /var/tmp/lost\+found -d gen_context(system_u:object_r:lost_found_t,mls_systemhigh)
> /var/tmp/lost\+found/.* <<none>>
> +/var/tmp/systemd-private-[^/]+ -d gen_context(system_u:object_r:tmp_t,s0-mls_systemhigh)
> +/var/tmp/systemd-private-[^/]+/tmp -d gen_context(system_u:object_r:tmp_t,s0-mls_systemhigh)
> +/var/tmp/systemd-private-[^/]+/tmp/.* <<none>>
> /var/tmp/vi\.recover -d gen_context(system_u:object_r:tmp_t,s0)
Merged. I think we should consider doing file context path
substitutions from /tmp to /var/tmp.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> 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(-)
>
> diff --git a/policy/support/obj_perm_sets.spt b/policy/support/obj_perm_sets.spt
> index 5e8718a8be67..cefc35f7b547 100644
> --- a/policy/support/obj_perm_sets.spt
> +++ b/policy/support/obj_perm_sets.spt
> @@ -178,7 +178,7 @@ define(`rw_lnk_file_perms',`{ getattr read write lock ioctl }')
> define(`create_lnk_file_perms',`{ create getattr }')
> define(`rename_lnk_file_perms',`{ getattr rename }')
> define(`delete_lnk_file_perms',`{ getattr unlink }')
> -define(`manage_lnk_file_perms',`{ create read write getattr setattr link unlink rename }')
> +define(`manage_lnk_file_perms',`{ create read write getattr setattr link unlink rename ioctl lock }')
> define(`relabelfrom_lnk_file_perms',`{ getattr relabelfrom }')
> define(`relabelto_lnk_file_perms',`{ getattr relabelto }')
> define(`relabel_lnk_file_perms',`{ getattr relabelfrom relabelto }')
Merged.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
> ---
> policy/modules/kernel/filesystem.if | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/policy/modules/kernel/filesystem.if b/policy/modules/kernel/filesystem.if
> index d24ae64f72b0..74d7b7321257 100644
> --- a/policy/modules/kernel/filesystem.if
> +++ b/policy/modules/kernel/filesystem.if
> @@ -4607,7 +4607,7 @@ interface(`fs_unmount_all_fs',`
> ## <desc>
> ## <p>
> ## Allow the specified domain to
> -## et the attributes of all filesystems.
> +## get the attributes of all filesystems.
> ## Example attributes:
> ## </p>
> ## <ul>
Merged.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | 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
2014-08-25 17:04 GMT+02:00 Christopher J. PeBenito:
> On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
>> 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?
>
I just remembered something I've read when I first set up SELinux on a
Debian system. Debian wiki says: "If you are using postfix, disable
chroot-support by running postfix-nochroot" [1]. So I guess Postfix
chrooting is not supported by Debian-SELinux developers.
Therefore I'm ok to drop this patch. Sorry for submitting it before
checking whether chrooted Postfix configurations were supported on
SELinux-enabled Debian.
Nicolas
[1]
https://wiki.debian.org/SELinux/Setup#mail_servers_.28postfix.2Fexim.2Fetc.29
2014-08-25 17:07 GMT+02:00 Christopher J. PeBenito:
> On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
>> ---
>> policy/support/obj_perm_sets.spt | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/policy/support/obj_perm_sets.spt b/policy/support/obj_perm_sets.spt
>> index 6e9131723cf4..5e8718a8be67 100644
>> --- a/policy/support/obj_perm_sets.spt
>> +++ b/policy/support/obj_perm_sets.spt
>> @@ -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]).
In fact, this patch comes from the old Debian patch to support systemd
[2]. It contained an awful amount of small changes not so much related
to systemd and the current Debian patches are much cleaner [3]. However
I applied the old patch on my Arch Linux policy to ease its development
and now I am splitting this patch in smaller patches which are much
easier to review (like the journald patches I sent a few days ago).
This is how I found this change, which made sense to me as socket and
dccp_socket are obviously in the socket class. Moreover Fedora policy
also has socket and dccp_socket in socket_class_set [4].
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?
--
Nicolas
[1] http://www.selinuxproject.org/page/ObjectClassesPerms#common_socket
[2]
http://anonscm.debian.org/cgit/selinux/refpolicy.git/tree/debian/patches/0100-systemd?id=b932d84a24c8edc07c95f92a96093e16bef043c8#n58
[3] http://anonscm.debian.org/cgit/selinux/refpolicy.git/tree/debian/patches
[4]
https://git.fedorahosted.org/cgit/selinux-policy.git/tree/policy/support/obj_perm_sets.spt?h=rawhide-base&id=f85b52d1c6805e9b0a8bd2a4a4332e66e4b52c00#n31
[5]
https://github.com/TresysTechnology/refpolicy-contrib/blob/21f961a147a9a08583825bdbe7cce43cf8fdc43d/mozilla.te#L80
On 8/26/2014 1:22 PM, Nicolas Iooss wrote:
> 2014-08-25 17:07 GMT+02:00 Christopher J. PeBenito:
>> On 8/23/2014 7:35 AM, Nicolas Iooss wrote:
>>> @@ -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]).
To be more specific, it refers to sockets that have no defined SELinux
object class. It is a fallback object class.
> 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;
I did some digging and found that rule was pulled in from the NSA
example policy. I don't know why it's there or if it is still needed.
> 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?
It would depend on the application; you would have to identify what type
of sockets that are being used, and then we'd have to add new object
classes. I'd be happy to remove them if it can be demonstrated that
they are no longer needed.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | 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
On Wed, 2014-08-27 at 23:51 +0200, Nicolas Iooss wrote:
> > 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
On Thu, 2014-08-28 at 09:06 +0200, Dominick Grift wrote:
> On Wed, 2014-08-27 at 23:51 +0200, Nicolas Iooss wrote:
>
> > > 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
>
You know, I do not know.
I never understood the audit_access av perm (the part where it only
works with dontaudit te rules). All i know is that it "works" for me.
I would not consider this to be a bug. Access checks happen all over
the place, and i suppose for good reasons.
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
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
http://www.tresys.com | oss.tresys.com
On a SE Linux system chrooting Postfix (and most daemons for that matter) requires granting MORE privileges to the daemon. Enabling that configuration makes things more difficult with no benefit.
The only possible benefit to enabling chroot is for a system that's not running SE Linux all the time. But it should be easy to revert the postfix-nochroot change for that situation (file a Debian bug report if it's too difficult to revert).
--
Sent from my Samsung Galaxy Note 2 with K-9 Mail.