On Sun, Sep 18, 2016 at 12:57:57PM -0700, Andy Lutomirski wrote: > On Sep 18, 2016 5:05 AM, "Jann Horn" <jann@xxxxxxxxx> 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.)
Attachment:
signature.asc
Description: Digital signature
