Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 529208 - dmesg requires access to kmsg_device_t
Summary: dmesg requires access to kmsg_device_t
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: SELinux (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sven Vermeulen (RETIRED)
URL:
Whiteboard: sec-policy r1
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-14 04:29 UTC by Eric Gisse
Modified: 2014-12-21 14:14 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Gisse 2014-11-14 04:29:50 UTC
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
Comment 1 Eric Gisse 2014-11-15 11:24:47 UTC
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(`
Comment 2 Sven Vermeulen (RETIRED) gentoo-dev 2014-11-15 18:50:17 UTC
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.
Comment 3 Sven Vermeulen (RETIRED) gentoo-dev 2014-11-27 22:18:48 UTC
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
Comment 4 Sven Vermeulen (RETIRED) gentoo-dev 2014-11-27 22:19:13 UTC
In repo, will be in rev 8
Comment 5 Sven Vermeulen (RETIRED) gentoo-dev 2014-12-21 14:14:16 UTC
r1 is now stable