On Tue, Jun 4, 2019 at 6:18 PM Stephen Smalley
<[email protected]> wrote:
>
> On Tue, Jun 4, 2019 at 4:58 PM Andy Lutomirski <[email protected]> wrote:
>>
>> On Tue, Jun 4, 2019 at 1:39 PM David Howells <[email protected]> wrote:
>> >
>> > Andy Lutomirski <[email protected]> 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.

Reply via email to