Upstreaming Gentoo policy updates
cover Upstreaming Gentoo policy updates
This is a set of updates that we apply to the Gentoo policy branch for non-contrib stuff.
Sven Vermeulen (5):
Hide getattr denials upon sudo invocation
Fix avc_context_to_raw assertion (avc_running) failure upon running
groupadd or useradd
Support /sys/devices/system/cpu/online
The security_t file system can be at /sys/fs/selinux Dontaudit access on security_t file system at /sys/fs/selinux
policy/modules/admin/sudo.if | 1 + policy/modules/admin/usermanage.te | 2 ++ policy/modules/kernel/devices.fc | 1 + policy/modules/kernel/devices.if | 61 ++++++++++++++++++++++++++++++++++++++ policy/modules/kernel/devices.te | 7 +++++ policy/modules/kernel/domain.te | 3 ++ policy/modules/kernel/selinux.if | 14 +++++++++ 7 files changed, 89 insertions(+)
Signature · 1 line
1.8.3.2
PATCH 1/5 Hide getattr denials upon sudo invocation
When sudo is invoked (sudo -i) the audit log gets quite a lot of denials related to the getattr permission against tty_device_t:chr_file for the *_sudo_t domain. However, no additional logging (that would hint at a need) by sudo, nor any functional issues come up.
Hence the dontaudit call.
--- policy/modules/admin/sudo.if | 1 + 1 file changed, 1 insertion(+)
policy/modules/admin/sudo.if +1 -0
@@ -110,6 +110,7 @@ template(`sudo_role_template',` selinux_compute_relabel_context($1_sudo_t) term_getattr_pty_fs($1_sudo_t) + term_dontaudit_getattr_unallocated_ttys($1_sudo_t) term_relabel_all_ttys($1_sudo_t) term_relabel_all_ptys($1_sudo_t)
Signature · 1 line
1.8.3.2
PATCH 1/5 Hide getattr denials upon sudo invocation
Quoted 6 lines · Sven Vermeulen
When sudo is invoked (sudo -i) the audit log gets quite a lot of denials related to the getattr permission against tty_device_t:chr_file for the
*_sudo_tdomain. However, no additional logging (that would hint at a need) by sudo, nor any functional issues come up.Hence the dontaudit call.
Merged.
Quoted 18 lines
Signed-off-by Sven Vermeulen <[email protected]>--- policy/modules/admin/sudo.if | 1 + 1 file changed, 1 insertion(+)policy/modules/admin/sudo.if +1
-0@@ -110,6 +110,7 @@ template(`sudo_role_template',` selinux_compute_relabel_context($1_sudo_t) term_getattr_pty_fs($1_sudo_t) + term_dontaudit_getattr_unallocated_ttys($1_sudo_t) term_relabel_all_ttys($1_sudo_t) term_relabel_all_ptys($1_sudo_t)
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 2/5 Fix avc_context_to_raw assertion (avc_running) failure upon running groupadd or useradd
In reply to Sven VermeulenWhen trying to create a group, the following error occurs:
~# groupadd test
groupadd: avc.c:74: avc_context_to_sid_raw: Assertion `avc_running' failed.
zsh: abort groupadd test
In the denial logs, the following AVC denial is shown:
Jan 23 13:57:17 maelstrom kernel: [11395.396588] type=1400
audit(1390481837.876:989): avc: denied { create } for pid=14296 comm="groupadd" scontext=staff_u:sysadm_r:groupadd_t tcontext=staff_u:sysadm_r:groupadd_t tclass=netlink_selinux_socket
In permissive mode, we notice that it both creates and binds to the netlink_selinux_socket.
Same with useradd.
Allowing the create/bind fixes the problem.
--- policy/modules/admin/usermanage.te | 2 ++ 1 file changed, 2 insertions(+)
policy/modules/admin/usermanage.te +2 -0
@@ -199,6 +199,7 @@ allow groupadd_t self:shm create_shm_perms; allow groupadd_t self:sem create_sem_perms; allow groupadd_t self:msgq create_msgq_perms; allow groupadd_t self:msg { send receive }; +allow groupadd_t self:netlink_selinux_socket { bind create }; allow groupadd_t self:unix_dgram_socket create_socket_perms; allow groupadd_t self:unix_stream_socket create_stream_socket_perms; allow groupadd_t self:unix_dgram_socket sendto;
@@ -459,6 +460,7 @@ allow useradd_t self:shm create_shm_perms; allow useradd_t self:sem create_sem_perms; allow useradd_t self:msgq create_msgq_perms; allow useradd_t self:msg { send receive }; +allow useradd_t self:netlink_selinux_socket { bind create }; allow useradd_t self:unix_dgram_socket create_socket_perms; allow useradd_t self:unix_stream_socket create_stream_socket_perms; allow useradd_t self:unix_dgram_socket sendto;
Signature · 1 line
1.8.3.2
PATCH 2/5 Fix avc_context_to_raw assertion (avc_running) failure upon running groupadd or useradd
Quoted 14 lines · Sven Vermeulen
When trying to create a group, the following error occurs:
~# groupadd test
groupadd: avc.c:74:avc_context_to_sid_raw: Assertion `avc_running' failed.
zsh: abort groupadd testIn the denial logs, the following AVC denial is shown:
Jan 23 13:57:17 maelstrom kernel: [11395.396588] type=1400audit(1390481837.876:989): avc: denied { create } for pid=14296 comm="groupadd" scontext=staff_u:sysadm_r:groupadd_t tcontext=staff_u:sysadm_r:groupadd_t tclass=netlink_selinux_socket
Quoted 6 lines
In permissive mode, we notice that it both creates and binds to the
netlink_selinux_socket.Same with useradd.
Allowing the create/bind fixes the problem.
I think we should start a new seutil interface which provides the necessary access for domains that have a userspace AVC. However, since this seems to only initialize a userspace AVC to do context_to_sid_raw, I wonder if it makes sense to keep this explicit netlink_selinux_socket access.
Quoted 26 lines
Signed-off-by Sven Vermeulen <[email protected]>--- policy/modules/admin/usermanage.te | 2 ++ 1 file changed, 2 insertions(+)policy/modules/admin/usermanage.te +2
-0@@ -199,6 +199,7 @@ allow groupadd_t self:shm create_shm_perms; allow groupadd_t self:sem create_sem_perms; allow groupadd_t self:msgq create_msgq_perms; allow groupadd_t self:msg { send receive }; +allow groupadd_t self:netlink_selinux_socket { bind create }; allow groupadd_t self:unix_dgram_socket create_socket_perms; allow groupadd_t self:unix_stream_socket create_stream_socket_perms; allow groupadd_t self:unix_dgram_socket sendto;@@ -459,6 +460,7 @@ allow useradd_t self:shm create_shm_perms; allow useradd_t self:sem create_sem_perms; allow useradd_t self:msgq create_msgq_perms; allow useradd_t self:msg { send receive }; +allow useradd_t self:netlink_selinux_socket { bind create }; allow useradd_t self:unix_dgram_socket create_socket_perms; allow useradd_t self:unix_stream_socket create_stream_socket_perms; allow useradd_t self:unix_dgram_socket sendto;
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 2/5 Fix avc_context_to_raw assertion (avc_running) failure upon running groupadd or useradd
Quoted 23 lines · Christopher J. PeBenito
Quoted 14 lines · Sven Vermeulen
When trying to create a group, the following error occurs:
~# groupadd test
groupadd: avc.c:74:avc_context_to_sid_raw: Assertion `avc_running' failed.
zsh: abort groupadd testIn the denial logs, the following AVC denial is shown:
Jan 23 13:57:17 maelstrom kernel: [11395.396588] type=1400audit(1390481837.876:989): avc: denied { create } for pid=14296 comm="groupadd" scontext=staff_u:sysadm_r:groupadd_t tcontext=staff_u:sysadm_r:groupadd_t tclass=netlink_selinux_socket
Quoted 6 lines
In permissive mode, we notice that it both creates and binds to the
netlink_selinux_socket.Same with useradd.
Allowing the create/bind fixes the problem.
I think we should start a new seutil interface which provides the necessary access for domains that have a userspace AVC. However, since this seems to only initialize a userspace AVC to do
context_to_sid_raw, I wonder if it makes sense to keep this explicitnetlink_selinux_socketaccess.
[...]
Quoted 1 line
Quoted 1 line
+allow
groupadd_tself:netlink_selinux_socket { bind create };
Hi Chris & refpolicy folks
I'm afraid I don't follow.
I understand that netlink_selinux_socket class is related to userspace SELinux support (netlink interface for interaction between userspace and kernel towards the SELinux subsystem) but you lost me at "to only initialize a userspace AVC to do context_to_sid_raw".
Do you mean that the permissions (bind + create) do not really mean that there is any communication otherwise (as there is no send_msg/recv_msg)? If so, does this then mean that the application shouldn't be calling avc_context_to_sid_raw at all?
Wkr,
Sven Vermeulen
PATCH 2/5 Fix avc_context_to_raw assertion (avc_running) failure upon running groupadd or useradd
Quoted 27 lines · Sven Vermeulen
Quoted 23 lines · Christopher J. PeBenito
Quoted 14 lines · Sven Vermeulen
When trying to create a group, the following error occurs:
~# groupadd test
groupadd: avc.c:74:avc_context_to_sid_raw: Assertion `avc_running' failed.
zsh: abort groupadd testIn the denial logs, the following AVC denial is shown:
Jan 23 13:57:17 maelstrom kernel: [11395.396588] type=1400audit(1390481837.876:989): avc: denied { create } for pid=14296 comm="groupadd" scontext=staff_u:sysadm_r:groupadd_t tcontext=staff_u:sysadm_r:groupadd_t tclass=netlink_selinux_socket
Quoted 6 lines
In permissive mode, we notice that it both creates and binds to the
netlink_selinux_socket.Same with useradd.
Allowing the create/bind fixes the problem.
I think we should start a new seutil interface which provides the necessary access for domains that have a userspace AVC. However, since this seems to only initialize a userspace AVC to do
context_to_sid_raw, I wonder if it makes sense to keep this explicitnetlink_selinux_socketaccess.[...]
Quoted 1 line
Quoted 1 line
+allow
groupadd_tself:netlink_selinux_socket { bind create };
Quoted 8 lines
Hi Chris & refpolicy folks
I'm afraid I don't follow.
I understand that
netlink_selinux_socketclass is related to userspace SELinux support (netlink interface for interaction between userspace and kernel towards the SELinux subsystem) but you lost me at "to only initialize a userspace AVC to docontext_to_sid_raw".
Well as far as I know, there aren't any reasons for groupadd to run a userspace AVC (it's not an object manager). However, to do context_to_sid_raw, it needs to have one running (hence the assertion that failed above). I'd like to start putting together an interface that domains that have a userspace AVC can use, which provides all the necessary access for the AVC to work.
Quoted 2 lines
Do you mean that the permissions (bind + create) do not really mean that there is any communication otherwise (as there is no send_msg/recv_msg)? If
Yes, but due to no read/write perms.
Quoted 2 lines
so, does this then mean that the application shouldn't be calling
avc_context_to_sid_rawat all?
I'm not suggesting that, as I haven't looked at the code.
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 3/5 Support /sys/devices/system/cpu/online
In reply to Sven VermeulenIn glibc, the get_nprocs method reads /sys/devices/system/cpu/online, so we need to grant most domains read access to this file. As we don't want them to have read access on sysfs_t by default, create a new type (cpu_online_t) and assign it to the file, and grant domains read access to the file.
This does require systems to relabel the file upon every boot, something distributions do in their bootup scripts, as /sys devices don't keep their context.
--- policy/modules/kernel/devices.fc | 1 + policy/modules/kernel/devices.if | 25 +++++++++++++++++++++++++ policy/modules/kernel/devices.te | 7 +++++++ policy/modules/kernel/domain.te | 3 +++ 4 files changed, 36 insertions(+)
policy/modules/kernel/devices.fc +1 -0
@@ -199,6 +199,7 @@ ifdef(`distro_debian',` /lib/udev/devices/zero -c gen_context(system_u:object_r:zero_device_t,s0) /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) ifdef(`distro_redhat',` # originally from named.fc
policy/modules/kernel/devices.if +25 -0
@@ -4854,6 +4854,31 @@ interface(`dev_create_zero_dev',` ######################################## ## <summary> +## Read cpu online hardware state information +## </summary> +## <desc> +## <p> +## Allow the specified domain to read /sys/devices/system/cpu/online +## </p> +## </desc> +## <param name="domain"> +## <summary> +## Domain allowed access. +## </summary> +## </param> +# +interface(`dev_read_cpu_online',` + gen_require(` + type cpu_online_t; + ') + + allow $1 cpu_online_t:file read_file_perms; + + dev_search_sysfs($1) +') + +######################################## +## <summary> ## Unconfined access to devices. ## </summary> ## <param name="domain">
policy/modules/kernel/devices.te +7 -0
@@ -60,6 +60,13 @@ type cpu_device_t; dev_node(cpu_device_t) # +# /sys/devices/system/cpu/online device +# +type cpu_online_t; +files_type(cpu_online_t) +dev_associate_sysfs(cpu_online_t) + +# # Type for /dev/crash # type crash_device_t;
policy/modules/kernel/domain.te +3 -0
@@ -96,6 +96,9 @@ kernel_dontaudit_link_key(domain) # create child processes in the domain allow domain self:process { fork sigchld }; +# glibc get_nprocs requires read access to /sys/devices/system/cpu/online +dev_read_cpu_online(domain) + # Use trusted objects in /dev dev_rw_null(domain) dev_rw_zero(domain)
Signature · 1 line
1.8.3.2
PATCH 3/5 Support /sys/devices/system/cpu/online
Quoted 9 lines · Sven Vermeulen
In glibc, the
get_nprocsmethod reads/sys/devices/system/cpu/online, so we need to grant most domains read access to this file. As we don't want them to have read access onsysfs_tby default, create a new type (cpu_online_t) and assign it to the file, and grant domains read access to the file.This does require systems to relabel the file upon every boot, something distributions do in their bootup scripts, as /sys devices don't keep their context.
Merged.
Quoted 89 lines
Signed-off-by Sven Vermeulen <[email protected]>--- policy/modules/kernel/devices.fc | 1 + policy/modules/kernel/devices.if | 25 +++++++++++++++++++++++++ policy/modules/kernel/devices.te | 7 +++++++ policy/modules/kernel/domain.te | 3 +++ 4 files changed, 36 insertions(+)policy/modules/kernel/devices.fc +1
-0@@ -199,6 +199,7 @@ ifdef(`distro_debian',` /lib/udev/devices/zero -c gen_context(system_u:object_r:zero_device_t,s0) /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) ifdef(`distro_redhat',` # originally from named.fcpolicy/modules/kernel/devices.if +25
-0@@ -4854,6 +4854,31 @@ interface(`dev_create_zero_dev',` ######################################## ## <summary> +## Read cpu online hardware state information +## </summary> +## <desc> +## <p> +## Allow the specified domain to read /sys/devices/system/cpu/online +## </p> +## </desc> +## <param name="domain"> +## <summary> +## Domain allowed access. +## </summary> +## </param> +# +interface(`dev_read_cpu_online',` + gen_require(` + type cpu_online_t; + ') + + allow $1 cpu_online_t:file read_file_perms; + + dev_search_sysfs($1) +') + +######################################## +## <summary> ## Unconfined access to devices. ## </summary> ## <param name="domain">policy/modules/kernel/devices.te +7
-0@@ -60,6 +60,13 @@ type cpu_device_t; dev_node(cpu_device_t) # +# /sys/devices/system/cpu/online device +# +type cpu_online_t; +files_type(cpu_online_t) +dev_associate_sysfs(cpu_online_t) + +# # Type for /dev/crash # type crash_device_t;policy/modules/kernel/domain.te +3
-0@@ -96,6 +96,9 @@ kernel_dontaudit_link_key(domain) # create child processes in the domain allow domain self:process { fork sigchld }; +# glibc get_nprocs requires read access to /sys/devices/system/cpu/online +dev_read_cpu_online(domain) + # Use trusted objects in /dev dev_rw_null(domain) dev_rw_zero(domain)
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 4/5 The security_t file system can be at /sys/fs/selinux
In reply to Sven VermeulenBecause it is no longer a top-level file system, we need to enhance some of the interfaces with the appropriate rights towards sysfs_t.
First set to allow getattr rights on the file system, which now also means getattr on the sysfs_t file system as well as search privileges in sysfs_t.
--- policy/modules/kernel/devices.if | 18 ++++++++++++++++++ policy/modules/kernel/selinux.if | 10 ++++++++++ 2 files changed, 28 insertions(+)
policy/modules/kernel/devices.if +18 -0
@@ -3873,6 +3873,24 @@ interface(`dev_getattr_sysfs_dirs',` ######################################## ## <summary> +## Get the attributes of sysfs filesystem +## </summary> +## <param name="domain"> +## <summary> +## Domain allowed access. +## </summary> +## </param> +# +interface(`dev_getattr_sysfs_fs',` + gen_require(` + type sysfs_t; + ') + + allow $1 sysfs_t:filesystem getattr; +') + +######################################## +## <summary> ## Search the sysfs directories. ## </summary> ## <param name="domain">
policy/modules/kernel/selinux.if +10 -0
@@ -63,6 +63,10 @@ interface(`selinux_get_fs_mount',` # (/selinux) is already a selinuxfs allow $1 security_t:filesystem getattr; + # Same for /sys/fs/selinux + dev_getattr_sysfs_fs($1) + dev_search_sysfs($1) + # read /proc/filesystems to see if selinuxfs is supported # then read /proc/self/mount to see where selinuxfs is mounted kernel_read_system_state($1)
@@ -165,6 +169,9 @@ interface(`selinux_getattr_fs',` ') allow $1 security_t:filesystem getattr; + + dev_getattr_sysfs_fs($1) + dev_search_sysfs($1) ') ########################################
@@ -184,6 +191,9 @@ interface(`selinux_dontaudit_getattr_fs',` ') dontaudit $1 security_t:filesystem getattr; + + dev_dontaudit_getattr_sysfs_fs($1) + dev_dontaudit_search_sysfs($1) ') ########################################
Signature · 1 line
1.8.3.2
PATCH 4/5 The security_t file system can be at /sys/fs/selinux
Quoted 20 lines · Sven Vermeulen
Because it is no longer a top-level file system, we need to enhance some of the interfaces with the appropriate rights towards
sysfs_t.First set to allow getattr rights on the file system, which now also means getattr on the
sysfs_tfile system as well as search privileges insysfs_t.Signed-off-by Sven Vermeulen <[email protected]>--- policy/modules/kernel/devices.if | 18 ++++++++++++++++++ policy/modules/kernel/selinux.if | 10 ++++++++++ 2 files changed, 28 insertions(+)policy/modules/kernel/devices.if +0
-0@@ -3873,6 +3873,24 @@ interface(`dev_getattr_sysfs_dirs',` ########################################
policy/modules/kernel/devices.if interface(`dev_getattr_sysfs_dirs',` · line 3884
Quoted 10 lines
policy/modules/kernel/devices.if +9
-0## <summary> +## Get the attributes of sysfs filesystem +## </summary> +## <param name="domain"> +## <summary> +## Domain allowed access. +## </summary> +## </param> +# +interface(`dev_getattr_sysfs_fs',`
I think if we simplify this to dev_getattr_sysfs(), also the similar change in patch 5, it can be merged.
Quoted 48 lines
policy/modules/kernel/devices.if +9
-0+ gen_require(` + type sysfs_t; + ') + + allow $1 sysfs_t:filesystem getattr; +') + +######################################## +## <summary> ## Search the sysfs directories. ## </summary> ## <param name="domain">policy/modules/kernel/selinux.if +10
-0@@ -63,6 +63,10 @@ interface(`selinux_get_fs_mount',` # (/selinux) is already a selinuxfs allow $1 security_t:filesystem getattr; + # Same for /sys/fs/selinux + dev_getattr_sysfs_fs($1) + dev_search_sysfs($1) + # read /proc/filesystems to see if selinuxfs is supported # then read /proc/self/mount to see where selinuxfs is mounted kernel_read_system_state($1)@@ -165,6 +169,9 @@ interface(`selinux_getattr_fs',` ') allow $1 security_t:filesystem getattr; + + dev_getattr_sysfs_fs($1) + dev_search_sysfs($1) ') ########################################@@ -184,6 +191,9 @@ interface(`selinux_dontaudit_getattr_fs',` ') dontaudit $1 security_t:filesystem getattr; + + dev_dontaudit_getattr_sysfs_fs($1) + dev_dontaudit_search_sysfs($1) ') ########################################
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH 5/5 Dontaudit access on security_t file system at /sys/fs/selinux
In reply to Sven VermeulenSecond part of the support of security_t under /sys/fs/selinux - when asked not to audit getting attributes on the selinux file system, have this propagate to the sysfs parts as well.
--- policy/modules/kernel/devices.if | 18 ++++++++++++++++++ policy/modules/kernel/selinux.if | 4 ++++ 2 files changed, 22 insertions(+)
policy/modules/kernel/devices.if +18 -0
@@ -3891,6 +3891,24 @@ interface(`dev_getattr_sysfs_fs',` ######################################## ## <summary> +## Do not audit getting the attributes of sysfs filesystem +## </summary> +## <param name="domain"> +## <summary> +## Domain to dontaudit access from +## </summary> +## </param> +# +interface(`dev_dontaudit_getattr_sysfs_fs',` + gen_require(` + type sysfs_t; + ') + + dontaudit $1 sysfs_t:filesystem getattr; +') + +######################################## +## <summary> ## Search the sysfs directories. ## </summary> ## <param name="domain">
policy/modules/kernel/selinux.if +4 -0
@@ -93,6 +93,10 @@ interface(`selinux_dontaudit_get_fs_mount',` # (/selinux) is already a selinuxfs dontaudit $1 security_t:filesystem getattr; + # Same for /sys/fs/selinux + dev_dontaudit_getattr_sysfs_fs($1) + dev_dontaudit_search_sysfs($1) + # read /proc/filesystems to see if selinuxfs is supported # then read /proc/self/mount to see where selinuxfs is mounted kernel_dontaudit_read_system_state($1)
Signature · 1 line
1.8.3.2