On 30/09/13 10:41, Dan Rosenberg wrote: > On 09/29/2013 07:41 PM, George Spelvin wrote: >>> Right, so the pppd application is actually doing the correct thing. >> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more >> immediate security hole than leaking kernel addresses. After all >> kptr_restrict is optional precisely because the benefit is marginal. >> >> The interesting question is what credentials make sense for %pK outside >> of a seq_printf(). Does it even make sense in a generic printk? In that >> case, it's the permission of the syslogd that matters rather than the >> process generating the message. >> >>> Will wait and see what others have to say. >> Me, too. Dan in particular. > > Firstly, I wouldn't recommend applying %pK's to printk usage.
Sorry, the patch description should say 'vsprintf: ' not 'printk: '. Posting too early in the morning :-). > Removing > all addresses from the kernel syslog compromises its usefulness in > debugging basically anything at all. Additionally, many printk calls are > performed from a context where a capability check would yield > unpredictable (or at least meaningless) results. If you want to restrict > access to the kernel syslog by unprivileged users, that should be done > by enabling CONFIG_DMESG_RESTRICT, which was written for this purpose. Agreed. > With that out of the way, I don't have a strong opinion on how to handle > this case. The proposed patch solves the problem but may break setuid > applications that expect to be able to read /proc/kallsyms contents > based on euid (and implicitly, capabilities) alone. But then again, > these mythical setuid applications are probably broken in some > situations anyway, because what happens if /proc/kallsyms is set to "2" > (unconditionally replace addresses with 0's)? I also can't think of a > better solution. Okay, this was just the simplest solution I could come up with that fixed the issue for me. Is that a tentative acked/reviewed-by? :-). ~Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
