On Fri, Jan 22, 2016 at 09:10:07PM -0600, Eric W. Biederman wrote: > Kees Cook <keesc...@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. :/
signature.asc
Description: Digital signature
