Messages in this thread | | | Date | Sat, 23 Jan 2016 23:25:40 +0100 | From | Jann Horn <> | 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@chromium.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. :/ [unhandled content-type:application/pgp-signature] | |