On Mon, Apr 29, 2013 at 4:47 PM, Andrew Morton <[email protected]> wrote: > On Mon, 29 Apr 2013 19:38:04 -0400 Josh Boyer <[email protected]> wrote: > >> On Mon, Apr 29, 2013 at 04:17:21PM -0700, [email protected] wrote: >> > From: Josh Boyer <[email protected]> >> > Subject: kmsg: honor dmesg_restrict sysctl on /dev/kmsg >> > >> > The dmesg_restrict sysctl currently covers the syslog method for access >> > dmesg, however /dev/kmsg isn't covered by the same protections. Most >> > people haven't noticed because util-linux dmesg(1) defaults to using the >> > syslog method for access in older versions. With util-linux dmesg(1) >> > defaults to reading directly from /dev/kmsg. >> > >> > Fix this by reworking all of the access methods to use the >> > check_syslog_permissions function and adding checks to devkmsg_open and >> > devkmsg_read. >> > >> > Addresses https://bugzilla.redhat.com/show_bug.cgi?id=903192 >> > >> > Signed-off-by: Eric Paris <[email protected]> >> > Signed-off-by: Josh Boyer <[email protected]> >> > Reported-by: Christian Kujau <[email protected]> >> > Acked-by: Kees Cook <[email protected]> >> > Cc: <[email protected]> >> > Signed-off-by: Andrew Morton <[email protected]> >> >> This version of the patch was found to cause dmesg(1) to no longer be >> able to use /dev/kmsg without CAP_SYSLOG. Kay and the Karel Zak thought >> that was a regression, so I sent out a v3 in the same thread. Kees had >> some issues with it, but I haven't seen a better proposal yet. > > Thanks, I missed that. > > Do we have a way forward? I like Linus's idea of nuking the > dmesg_restrict feature ;)
Please no; this is a feature people depend on. Security checks need to be done at open time. The /dev/kmsg misbehavior associated with this patch was related to the interaction with CAP_SYSLOG, not dmesg_restrict. (The new dmesg fell back to syscalls when it couldn't open /dev/kmsg.) -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
