lkml.org 
[lkml]   [2018]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications
Date
Casey Schaufler <casey@schaufler-ca.com> 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?

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.

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.

> > (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.

> 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?

David

\
 
 \ /
  Last update: 2018-07-24 18:01    [W:0.152 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site