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? Christian. -- BOFH excuse #260: We're upgrading /dev/null -- 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