Re: [PATCH v2 3/4] sysctl: allow for strict write position handling

[Andrew Morton]

On Mon, 21 Apr 2014 21:52:48 -0700 Kees Cook <keescook@xxxxxxxxxxxx> wrote:

> >> 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"?

Yes, I suppose that's more flexible.

I do have my doubts about whether we'll ever be able to change the
behaviour.  There will be soooo many random proc-pokers out there and
the amount of dusty-deck software will only increase over time.

I suppose the first thing to do is to get the warning in there and see
if we can get an understanding of how much code is likely to be
affected by the change.  Add "please email Kees" to the printk ;) I did
that once, many years ago.  I got a lot of email.  Didn't do it again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/