On Tue, Jun 4, 2019 at 6:18 PM Stephen Smalley <stephen.smalley@xxxxxxxxx> wrote: > > On Tue, Jun 4, 2019 at 4:58 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: >> >> On Tue, Jun 4, 2019 at 1:39 PM David Howells <dhowells@xxxxxxxxxx> wrote: >> > >> > Andy Lutomirski <luto@xxxxxxxxxx> wrote: >> > >> > > > Here's a set of patches to add a general variable-length notification queue >> > > > concept and to add sources of events for: >> > > >> > > I asked before and didn't see a response, so I'll ask again. Why are you >> > > paying any attention at all to the creds that generate an event? >> > >> > Casey responded to you. It's one of his requirements. >> > >> >> It being a "requirement" doesn't make it okay. >> >> > However, the LSMs (or at least SELinux) ignore f_cred and use current_cred() >> > when checking permissions. See selinux_revalidate_file_permission() for >> > example - it uses current_cred() not file->f_cred to re-evaluate the perms, >> > and the fd might be shared between a number of processes with different creds. >> >> That's a bug. It's arguably a rather severe bug. If I ever get >> around to writing the patch I keep thinking of that will warn if we >> use creds from invalid contexts, it will warn. > > > No, not a bug. Working as designed. Initial validation on open, but revalidation upon read/write if something has changed since open (process SID differs from opener, inode SID has changed, policy has changed). Current subject SID should be used for the revalidation. It's a MAC vs DAC difference. > Can you explain how the design is valid, then? Consider nasty cases like this: $ sudo -u lotsofgarbage 2>/dev/whatever It is certainly the case that drivers, fs code, and other core code MUST NOT look at current_cred() in the context of syscalls like open(). Jann, I, and others have found quite a few rootable bugs of this sort. What makes MAC special here? I would believe there are cases where auditing write() callers makes some sense, but anyone reading those logs needs to understand that the creds are dubious at best.
