From: Casey Schaufler <firstname.lastname@example.org>
To: David Howells <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Subject: Re: [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications
Date: Tue, 24 Jul 2018 11:57:37 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 7/24/2018 9:00 AM, David Howells wrote:
> Casey Schaufler <email@example.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?
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
> 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
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.
next prev parent reply other threads:[~2018-07-24 20:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 15:25 [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications David Howells
2018-07-23 15:25 ` [PATCH 1/5] General notification queue with user mmap()'able ring buffer David Howells
2018-07-23 15:25 ` [PATCH 2/5] KEYS: Add a notification facility David Howells
2018-07-23 15:26 ` [PATCH 3/5] vfs: Add a mount-notification facility David Howells
2018-07-23 15:26 ` [PATCH 4/5] vfs: Add superblock notifications David Howells
2018-07-23 15:26 ` [PATCH 5/5] Add sample notification program David Howells
2018-07-23 16:31 ` [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications Casey Schaufler
2018-07-24 0:37 ` Ian Kent
2018-07-24 16:00 ` David Howells
2018-07-24 18:57 ` Casey Schaufler [this message]
2018-07-25 5:39 ` Ian Kent
2018-07-25 15:48 ` Casey Schaufler
2018-07-26 1:18 ` Ian Kent
2018-07-26 16:09 ` Casey Schaufler
2018-07-24 19:22 ` David Howells
2018-08-01 21:04 ` LSM hook for mount, superblock and keys watch notifications David Howells
2018-08-01 21:49 ` Casey Schaufler
2018-08-01 22:50 ` David Howells
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).