On Sun, Sep 18, 2016 at 12:57:57PM -0700, Andy Lutomirski wrote:
> On Sep 18, 2016 5:05 AM, "Jann Horn" <jann@thejh.net> wrote:
> >
> > This ensures that VFS implementations don't call ptrace_may_access() from
> > VFS read or write handlers. In order for file descriptor passing to have
> > its intended security properties, VFS read/write handlers must not do any
> > kind of privilege checking.
> >
> 
> Ooh, nifty!  Can you warn about capable() too?
> 
> Warning about all access to current->cred could be fun.  I expect we
> have zillions of these bugs.  Think keys, netlink, proc, etc.

True, that would probably spam dmesg quite a bit. %pK under printk() is
pretty nonsensical (heh, maybe we even have code doing capable() checks
in IRQ context via printk()), then there are all those broken capable()
checks for root-only sysctls and so on.

For capable(), I've been thinking about adopting Linus' old suggestion of
simply overriding the creds on VFS read/write entry. If we make
current->cred non-refcounted and task-private (no RCU-safe pointer
assignment), it's going to basically be two extra pointer reads and writes
per read/write call - even for such a hot code path, that should be fine
IMO. (And if we don't want to do this for all read/write calls, we could
at least do it for sysctls, that would already help quite a bit.)