Running the dmesg command under the sysadm_r spits out a bit of unhappiness: [51487.551138] audit: type=1400 audit(1415938334.759:762): avc: denied { read } for pid=11058 comm="dmesg" name="kmsg" dev="devtmpfs" ino=3080 ipaddr=173.173.113.156 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:kmsg_device_t tclass=chr_file permissive=1 [51487.551165] audit: type=1400 audit(1415938334.759:763): avc: denied { open } for pid=11058 comm="dmesg" path="/dev/kmsg" dev="devtmpfs" ino=3080 ipaddr=173.173.113.156 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:kmsg_device_t tclass=chr_file permissive=1 Makes sense - dmesg is accessing the kernel log. Fixing this is straight forward with the dev_read_kmsg() macro: diff --git a/policy/modules/admin/dmesg.te b/policy/modules/admin/dmesg.te index ee07743..0aca22b 100644 --- a/policy/modules/admin/dmesg.te +++ b/policy/modules/admin/dmesg.te @@ -19,6 +19,7 @@ dontaudit dmesg_t self:capability sys_tty_config; allow dmesg_t self:process signal_perms; +dev_read_kmsg(dmesg_t) kernel_read_kernel_sysctls(dmesg_t) kernel_read_ring_buffer(dmesg_t) kernel_clear_ring_buffer(dmesg_t) Reproducible: Always
Humph, when I did this I tested it and didn't see any further dmesg complaints so I called it a day. I check later, and it continues thus making me feel silly. Now I read it and think on it fresh, and I realize that dmesg is running in the sysadm_t user domain rather than under its' own domain. There is a dmesg_domtrans() interface, however the sysadm policy instead uses the dmesg_exec() interface which merely executes dmesg within sysadm_t, which doesn't have permission to use kmsg_device_t which is what my patch was *supposed* to solve. Which it would, if sysadm was using the interface I expected :p Classic "solving the wrong problem". Upon giving sysadm_t the dmesg_domtrans() macro, for which I can't think of a reason why that would be bad, the issue is solved. Combined patch: diff --git a/policy/modules/admin/dmesg.te b/policy/modules/admin/dmesg.te index ee07743..5a09bd7 100644 --- a/policy/modules/admin/dmesg.te +++ b/policy/modules/admin/dmesg.te @@ -28,6 +28,7 @@ kernel_read_proc_symlinks(dmesg_t) # for when /usr is not mounted: kernel_dontaudit_search_unlabeled(dmesg_t) +dev_read_kmsg(dmesg_t) dev_read_sysfs(dmesg_t) fs_search_auto_mountpoints(dmesg_t) diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te index af9d2cf..54c3026 100644 --- a/policy/modules/roles/sysadm.te +++ b/policy/modules/roles/sysadm.te @@ -145,7 +145,9 @@ optional_policy(` ') optional_policy(` - dmesg_exec(sysadm_t) + +dmesg_domtrans(sysadm_t) +# dmesg_exec(sysadm_t) ') optional_policy(`
A domtrans doesn't suffice, because the dmesg_t type is not assigned to the sysadm_r role for instance. You'll need a dmesg_role() implementation for this. However, what is the purpose of accessing kmsg? When I enable access to /dev/kmsg my dmesg output hardly changes, and there is nothing new of information. In other words, it might even be better to dontaudit it instead of allowing it.
Okay, dmesg access to kmsg is pretty standard - and although it doesn't show differences in the majority of cases (because there is no info from kmsg) or because syslog is already capturing the info, having dmesg access the kmsg device (for reading) is still a possibly important aspect in case of problems (when syslog fails and such). So ACK on the suggested changes: dmesg_run() interface added dmesg_run(sysadm_t, sysadm_r) call added dev_read_kmsg(dmesg_t) added
In repo, will be in rev 8
r1 is now stable