On Tue, 30 Apr 2013 10:25:41 -0700 Kees Cook <[email protected]> wrote:
> To fix /dev/kmsg, let's compare the existing interfaces and what they allow: > > - /proc/kmsg allows: > - open (SYSLOG_ACTION_OPEN) if CAP_SYSLOG since it uses a destructive > single-reader interface (SYSLOG_ACTION_READ). > - everything, after an open. > > - syslog syscall allows: > - anything, if CAP_SYSLOG. > - SYSLOG_ACTION_READ_ALL and SYSLOG_ACTION_SIZE_BUFFER, if dmesg_restrict==0. > - nothing else (EPERM). > > The use-cases were: > - dmesg(1) needs to do non-destructive SYSLOG_ACTION_READ_ALLs. > - sysklog(1) needs to open /proc/kmsg, drop privs, and still issue the > destructive SYSLOG_ACTION_READs. > > AIUI, dmesg(1) is moving to /dev/kmsg, and systemd-journald doesn't > clear the ring buffer. > > Based on the comments in devkmsg_llseek, it sounds like actions besides > reading aren't going to be supported by /dev/kmsg (i.e. SYSLOG_ACTION_CLEAR), > so we have a strict subset of the non-destructive syslog syscall actions. > > To this end, move the check as Josh had done, but also rename the constants > to reflect their new uses (SYSLOG_FROM_CALL becomes SYSLOG_FROM_READER, and > SYSLOG_FROM_FILE becomes SYSLOG_FROM_PROC). SYSLOG_FROM_READER allows > non-destructive actions, and SYSLOG_FROM_PROC allows destructive actions > after a capabilities-constrained SYSLOG_ACTION_OPEN check. > > - /dev/kmsg allows: > - open if CAP_SYSLOG or dmesg_restrict==0 > - reading/polling, after open hm, that changelog is waaaay down in the weeds and anyone who hasn't been following this with a microscope won't have a clue. I went into an earlier patch and dug out this: : 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. : : Addresses https://bugzilla.redhat.com/show_bug.cgi?id=903192 Which is still accurate and relevant, yes? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
