Re: [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/24/2018 9:00 AM, David Howells wrote:
> Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>
>>>  (1) Mount topology and reconfiguration change events.
>> With the possibility of unprivileged mounting you're going to have to
>> address access control on events.  If root in a user namespace mounts a
>> filesystem you may have a case where the "real" user wouldn't want the
>> listener to receive a notification.
> Can you clarify who the listener is in this case?

That would be anyone with a watchpoint set.

> Note that mount topology events don't leak outside of the mount namespace
> they're generated in.
>
> That said, if you, a random user, put a watchpoint on "/" you can see the
> mount events triggered by another random user in the same mount namespace.  I
> don't see a way to control this except by resorting to the LSM since UNIX
> doesn't have 'notify' permission bits.

I would call that a write operation from the process that triggered
the watchpoint to the one watching it. Like a signal. Signals have a
rudimentary DAC policy (write only to the same UID) that could be
your model.

> But for each event, I can associate an object label, derived from the source,
> and use f_cred on the notification queue to provide a subject label.

... or UID or groups.

>
>>>  (2) Superblocks EIO, ENOSPC and EDQUOT events (not complete yet).
>> Here, too. If SELinux (for example) policy says you can't see
>> anything on a filesystem you shouldn't get notifications about
>> things that happen to that filesystem.
> Yep.  Sounds like I need to refer that to the LSM as above.
>
> It's a bit easier for specifically nominated sb sources since you might only
> need to do the check once at sb_notify() time.  If there's a general queue
> that all sbs contribute to, however, then things become more complicated as
> the checks have to be done at do-we-write-into-this-queue? time.
>
>>>  (3) Key/keyring changes events
>> And again, I should only get notifications about keys and
>> keyrings I have access to.
> Currently, you can only watch keys that grant you View permission, which might
> suffice.

That seems appropriate.

>> I expect that you intentionally left off
>>
>>    (4) User injected events
>>
>> at this point, but it's an obvious extension. That is going
>> to require access controls (remember kdbus) so I think you'd
>> do well to design them in now rather than have some security
>> module hack like me come along later and "fix" it. 
> Yeah - the thought had occurred to me, but there needs to be some way to
> define a 'source' and a way to connect them.  Also, would you want a general
> source that anyone can contribute through, specific sources where you have to
> directly connect or namespace-restricted sources?

My guess is that the consensus would be "Yes" to all the above.

>
> David
>




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux