archive mirror
 help / color / mirror / Atom feed
From: David Howells <>
To: Casey Schaufler <>
Subject: Re: [RFC][PATCH 0/5] Mount, Filesystem and Keyrings notifications
Date: Tue, 24 Jul 2018 20:22:49 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Casey Schaufler <> 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.

I was wanting clarification on how you viewed events being generated inside
the namespace being seen by an external listener, vs events being generated
outside the namespace being seen by an internal listener.

Hmmm...  OTOH, maybe it's not a problem - can a mount namespace intersect with
two different user namespaces, given it has its own user_ns pointer?

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

Might not be useful if the watched object doesn't have UID or GID - a
superblock say.

Also, that raises an additional question: if someone triggers an event - say a
mount - there is an additional set of creds (that of the triggering process).
Do I need to consider that?

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

I thought you might say that.


  parent reply	other threads:[~2018-07-24 20:30 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
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 [this message]
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

Reply instructions:

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