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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20140422111143.74a426009ee37027c948aebc@linux-foundation.org>
Date:	Tue, 22 Apr 2014 11:11:43 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Kees Cook <keescook@...omium.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Li Zefan <lizefan@...wei.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Aaron Tomlin <atomlin@...hat.com>,
	Dario Faggioli <raistlin@...ux.it>,
	Andrew Shewmaker <agshew@...il.com>,
	Andi Kleen <ak@...ux.intel.com>, Jens Axboe <axboe@...com>,
	Wanpeng Li <liwanp@...ux.vnet.ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrey Vagin <avagin@...nvz.org>,
	Michael Ellerman <michael@...erman.id.au>
Subject: Re: [PATCH v2 3/4] sysctl: allow for strict write position handling

On Mon, 21 Apr 2014 21:52:48 -0700 Kees Cook <keescook@...omium.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/