linux-kernel - Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax

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]

Date:	Sat, 23 Jan 2016 23:25:40 +0100
From:	Jann Horn <jann@...jh.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Richard Weinberger <richard@....at>,
	Andy Lutomirski <luto@...capital.net>,
	Robert Święcki <robert@...ecki.net>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	David Howells <dhowells@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of
 proc_dointvec_minmax_sysadmin

On Fri, Jan 22, 2016 at 09:10:07PM -0600, Eric W. Biederman wrote:
> Kees Cook <keescook@...omium.org> writes:
> 
> > Several sysctls expect a state where the highest value (in extra2) is
> > locked once set for that boot. Yama does this, and kptr_restrict should
> > be doing it. This extracts Yama's logic and adds it to the existing
> > proc_dointvec_minmax_sysadmin, taking care to avoid the simple boolean
> > states (which do not get locked). Since Yama wants to be checking a
> > different capability, we build wrappers for both cases (CAP_SYS_ADMIN
> > and CAP_SYS_PTRACE).
> 
> Sigh this sysctl appears susceptible to known attacks.
> 
> In my quick skim I believe this sysctl implementation that checks
> capabilities is susceptible to attacks where the already open file
> descriptor is set as stdout on a setuid root application.
> 
> Can we come up with an interface that isn't exploitable by an
> application that will act as a setuid cat?

Adding the struct file * to the parameters of all proc_handler
functions would work, right? (Or just filp->f_cred? That would be
less generic.)

A quick grep says that's just about 160 functions that'll need to
be changed. :/

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)