linux-kernel - Re: [PATCH 1/2] sysctl: add a new generic strategy to make permanent changes on negative values

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: <20150803185013.GA24014@1wt.eu>
Date:	Mon, 3 Aug 2015 20:50:13 +0200
From:	Willy Tarreau <w@....eu>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andy Lutomirski <luto@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"security@...nel.org" <security@...nel.org>,
	X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Jan Beulich <jbeulich@...e.com>,
	xen-devel <xen-devel@...ts.xen.org>
Subject: Re: [PATCH 1/2] sysctl: add a new generic strategy to make permanent changes on negative values

On Mon, Aug 03, 2015 at 11:33:30AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau <w@....eu> wrote:
> > The new function is proc_dointvec_minmax_negperm(), it refuses to change
> > the value if the current one is already negative. This will be used to
> > lock down some settings such as sensitive system calls.
> >
> > Signed-off-by: Willy Tarreau <w@....eu>
> > ---
> >  kernel/sysctl.c | 36 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 19b62b5..86c95a8 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -185,6 +185,9 @@ static int proc_dointvec_minmax_sysadmin(struct ctl_table *table, int write,
> >                                 void __user *buffer, size_t *lenp, loff_t *ppos);
> >  #endif
> >
> > +static int proc_dointvec_minmax_negperm(struct ctl_table *table, int write,
> > +               void __user *buffer, size_t *lenp, loff_t *ppos);
> > +
> >  static int proc_dointvec_minmax_coredump(struct ctl_table *table, int write,
> >                 void __user *buffer, size_t *lenp, loff_t *ppos);
> >  #ifdef CONFIG_COREDUMP
> > @@ -2249,6 +2252,33 @@ static void validate_coredump_safety(void)
> >  #endif
> >  }
> >
> > +/* Like minmax except that it refuses any change if the value was already
> > + * negative. It silently ignores overrides with the same negative value.
> > + */
> > +static int do_proc_dointvec_negperm_conv(bool *negp, unsigned long *lvalp,
> > +                                        int *valp,
> > +                                        int write, void *data)
> > +{
> > +       if (write && *valp < 0 && (!*negp || *valp != (int)*lvalp))
> 
> I could easily have failed to follow the bizarre negative sign
> convention, but shouldn't that be "*valp != -(int)*lvalp" or similar?

Not exactly since the sign is passed via negp apparently. There
is an expression in the called function which first assigns lvalp
or -lvalp to val depending on val, then uses the resulting value.

The code above is the (simplified for me) equivalent of :

     int val = *negp ? -*lvalp : *lvalp;

     if (write && *valp < 0 && *valp != val)
             return -EINVAL;

Maybe you find it more readable in which case I can redo it this way ?
In my case it was the opposite in fact, I want to reject non-negative
values as well as the negative ones not equal to *valp.

Note that we could have decided to make it even simpler and always
reject writes once *valp is < 0 but I find that it would be annoying
for hardening scripts which would not be idempotent anymore.

Willy

--
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/