On Mon, Apr 21, 2014 at 3:45 PM, Andrew Morton <a...@linux-foundation.org> wrote: > On Thu, 17 Apr 2014 17:16:22 -0700 Kees Cook <keesc...@chromium.org> wrote: > >> When writing to a sysctl string, each write, regardless of VFS position, >> begins writing the string from the start. This means the contents of >> the last write to the sysctl controls the string contents instead of >> the first: >> >> open("/proc/sys/kernel/modprobe", O_WRONLY) = 1 >> write(1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096 >> write(1, "/bin/true", 9) = 9 >> close(1) = 0 >> >> $ cat /proc/sys/kernel/modprobe >> /bin/true >> >> Expected behaviour would be to have the sysctl be "AAAA..." capped at >> maxlen (in this case KMOD_PATH_LEN: 256), instead of truncating to the >> contents of the second write. Similarly, multiple short writes would not >> append to the sysctl. >> >> This provides CONFIG_PROC_SYSCTL_STRICT_WRITES as a way to make this >> behavior act in a less surprising manner for strings, and disallows >> non-zero file position when writing numeric sysctls (similar to what is >> already done when reading from non-zero file positions). > > Adding a Kconfig knob to alter the behavior of procfs writes creeps me > out. I wonder why. > > - I doubt if many people have a sufficient amount of control over > their entire systems to be able to confidently set > CONFIG_PROC_SYSCTL_STRICT_WRITES. > > - Software will be shipped which runs OK with one setting but breaks > with the other setting. > > So what to do? > > I think we can *detect* this situation easily enough. So some options are > > a) change the behaviour and add code which detects when userspace is > doing a write whose behaviour is now altered. Print a warning. Or > > b) leave the behaviour as-is. Add a detector which tells people > "hey, your userspace is probably broken - please fix". Wait N > years. Then alter the behaviour as in a). > > In either case the detector should display current->comm, the procfs > pathname and the contents of the write, to aid people in hunting down > and fixing their userspace.
How about a tri-state sysctl (har har control sysctl behavior with a sysctl) that defaults ("1") to existing behavior (to not break anything) with a warning. Mode "2" uses new behavior, and mode "0" uses existing behavior without a warning? Then we can wait N years and switch the default to "2"? -Kees -- Kees Cook Chrome OS Security -- 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/