On Mon, Jun 10, 2013 at 1:47 AM, Christian Kujau <lists@xxxxxxxxxxxxxxx> wrote: > On Tue, 30 Apr 2013 at 08:15, Kees Cook wrote: >> > 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.) > > +1 for some kind of dmesg_restrict feature. Without removing > read-permission from /dev/kmsg during boot, users can still read from it. > While this may be useful for a lot of cases (bug reports), dmesg can > indeed contain sensitive information. > > At the moment, CONFIG_SECURITY_DMESG_RESTRICT can be set - but it's only > covering /proc/kmsg and syslog(), right? No worries, it's all getting fixed. This is what is currently in linux-next: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/kernel/printk.c?id=a0724f739207ca536bbdcbd3b532fe55310ba7d6 -Kees > > Christian. > -- > BOFH excuse #260: > > We're upgrading /dev/null -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html