Add boolean controlling user access to kernel keyring
PATCH 1/1 Add boolean controlling user access to kernel keyring
This patch adds the boolean "allow_kernel_keyring_user_access" with the goal of implementing an on/off switch for the kernel keyring as far as unprivileged users are concerned. It defaults to true which corresponds to the original behavior without this patch.
The reason for the patch is that the kernel keyring is a fairly complex piece of code that would need testing and documentation if it were available in the evaluated configuration for LSPP (labeled security protection profile) compliant systems, and since it's unlikely to currently be useful on those systems it would greatly simplify things to have a way to disable the feature for unprivileged users at runtime.
This is untested (other than checking that the policy compiles and toggling the boolean doesn't seem to do anything drastic), I don't currently have any test programs available for the kernel keyring. If someone can point me to something I'd be happy to verify it.
policy/modules/kernel/kernel.if | 10 ++++++++-- policy/modules/kernel/kernel.te | 3 +++ policy/modules/services/remotelogin.te | 4 +++- policy/modules/services/xserver.te | 8 ++++++-- policy/modules/system/locallogin.te | 4 +++- policy/modules/system/userdomain.if | 5 ++++- 6 files changed, 27 insertions(+), 7 deletions(-)
policy/modules/kernel/kernel.if +8 -2
@@ -1454,9 +1454,12 @@ interface(`kernel_search_key',` gen_require(` type kernel_t; + bool allow_kernel_keyring_user_access; ') - allow $1 kernel_t:key search; + if (allow_kernel_keyring_user_access) { + allow $1 kernel_t:key search; + } ') ########################################
@@ -1472,9 +1475,12 @@ interface(`kernel_link_key',` gen_require(` type kernel_t; + bool allow_kernel_keyring_user_access; ') - allow $1 kernel_t:key link; + if (allow_kernel_keyring_user_access) { + allow $1 kernel_t:key link; + } ') ########################################
policy/modules/kernel/kernel.te +3 -0
@@ -353,3 +353,6 @@ allow kern_unconfined unlabeled_t:packet *; kernel_rw_all_sysctls(kern_unconfined) + +# Are non-admin users permitted to use the kernel keyring facility? +bool allow_kernel_keyring_user_access true;
policy/modules/services/remotelogin.te +3 -1
@@ -33,7 +33,9 @@ allow remote_login_t self:sem create_sem_perms; allow remote_login_t self:msgq create_msgq_perms; allow remote_login_t self:msg { send receive }; -allow remote_login_t self:key write; +if (allow_kernel_keyring_user_access) { + allow remote_login_t self:key write; +} allow remote_login_t remote_login_tmp_t:dir create_dir_perms; allow remote_login_t remote_login_tmp_t:file create_file_perms;
policy/modules/services/xserver.te +6 -2
@@ -83,7 +83,9 @@ allow xdm_t self:capability { setgid setuid sys_resource kill sys_tty_config mknod chown dac_override dac_read_search fowner fsetid ipc_owner sys_nice sys_rawio net_bind_service }; allow xdm_t self:process { setexec setpgid getsched setsched setrlimit signal_perms setkeycreate }; allow xdm_t self:fifo_file rw_file_perms; -allow xdm_t self:key link; +if (allow_kernel_keyring_user_access) { + allow xdm_t self:key link; +} allow xdm_t self:shm create_shm_perms; allow xdm_t self:sem create_sem_perms; allow xdm_t self:unix_stream_socket { connectto create_stream_socket_perms };
@@ -93,7 +95,9 @@ allow xdm_t self:udp_socket create_socket_perms; allow xdm_t self:socket create_socket_perms; allow xdm_t self:appletalk_socket create_socket_perms; -allow xdm_t self:key { search write }; +if (allow_kernel_keyring_user_access) { + allow xdm_t self:key { search write }; +} # Supress permission check on .ICE-unix dontaudit xdm_t ice_tmp_t:dir { getattr setattr };
policy/modules/system/locallogin.te +3 -1
@@ -47,7 +47,9 @@ allow local_login_t self:sem create_sem_perms; allow local_login_t self:msgq create_msgq_perms; allow local_login_t self:msg { send receive }; -allow local_login_t self:key { search write }; +if (allow_kernel_keyring_user_access) { + allow local_login_t self:key { search write }; +} allow local_login_t local_login_lock_t:file create_file_perms; files_lock_filetrans(local_login_t,local_login_lock_t,file)
policy/modules/system/userdomain.if +4 -1
@@ -4748,9 +4748,12 @@ ifdef(`strict_policy',` gen_require(` attribute userdomain; + bool allow_kernel_keyring_user_access; ') - allow $1 userdomain:key create; + if (allow_kernel_keyring_user_access) { + allow $1 userdomain:key create; + } ',` unconfined_create_keys($1) ')
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 11 lines · Klaus Weidner
This patch adds the boolean "
allow_kernel_keyring_user_access" with the goal of implementing an on/off switch for the kernel keyring as far as unprivileged users are concerned. It defaults to true which corresponds to the original behavior without this patch.The reason for the patch is that the kernel keyring is a fairly complex piece of code that would need testing and documentation if it were available in the evaluated configuration for LSPP (labeled security protection profile) compliant systems, and since it's unlikely to currently be useful on those systems it would greatly simplify things to have a way to disable the feature for unprivileged users at runtime.
I'm confused, there isn't any unprivileged user access that is disabled by this policy, only login programs. Besides that, I really don't think this is needed because what you're saying is that you don't trust the key code. However, the code that enforces this policy is the code that you don't trust, so this policy wouldn't gain anything.
Signature · 9 lines
Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 13 lines · Christopher J. PeBenito
Quoted 11 lines · Klaus Weidner
This patch adds the boolean "
allow_kernel_keyring_user_access" with the goal of implementing an on/off switch for the kernel keyring as far as unprivileged users are concerned. It defaults to true which corresponds to the original behavior without this patch.The reason for the patch is that the kernel keyring is a fairly complex piece of code that would need testing and documentation if it were available in the evaluated configuration for LSPP (labeled security protection profile) compliant systems, and since it's unlikely to currently be useful on those systems it would greatly simplify things to have a way to disable the feature for unprivileged users at runtime.
Quoted 2 lines
I'm confused, there isn't any unprivileged user access that is disabled by this policy, only login programs.
My goal was to conditionalize all "allow" rules for operations on the key class in the current policy, based on a comment by Stephen Smalley that this would make the keys inaccessible. I was expecting that the user processes would inherit the permissions from the login program used to access the system, but that's apparently not how it works (sorry about the confusion).
I've now experimented with the keyctl program and it appears that the current policy already doesn't allow key operations for users. I'm getting "permission denied" errors for simple operations such as "keyctl add user mykey stuff @u" when run as a staff_u user.
If the current refpolicy already disables access to the keyring, and admins would need to add site-specific policy rules to allow it, I agree that the patch isn't necessary.
(If there are plans to make the keyring features available to general userspace programs by default in the refpolicy in the future, I think a boolean to control it would be useful at that time.)
Quoted 4 lines
Besides that, I really don't think this is needed because what you're saying is that you don't trust the key code. However, the code that enforces this policy is the code that you don't trust, so this policy wouldn't gain anything.
I don't mistrust it in the sense that I expect it to do anything malicious. The reason for the disabling switch is for the ongoing Common Criteria LSPP evaluations -- any IPC mechanism that the system offers to regular users needs to be fully documented and tested. That's a lot of work, and it doesn't seem justified in this case since it's not something that people running an MLS server would currently expect to be available. If the system always denies access due to the policy, that's easy to verify and will avoid the need for extensive testing and documentation.
-Klaus
--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.