On 6/12/19 7:43 AM, David Howells wrote:
Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
(6) The security attributes of all the objects between the object in (5)
and the object in (4), assuming we work from (5) towards (4) if the
two aren't coincident (WATCH_INFO_RECURSIVE).
Does this apply to anything other than mount notifications?
Not at the moment. I'm considering making it such that you can make a watch
on a keyring get automatically propagated to keys that get added to the
keyring (and removed upon unlink) - the idea being that there is no 'single
parent path' concept for a keyring as there is for a directory.
I'm also pondering the idea of making it possible to have superblock watches
automatically propagated to superblocks created by automount points on the
watched superblock.
So at the point where you can set a watch on one object O1 with label X,
and receive notifications triggered upon operations on another object O2
with label Y, we have to consider whether the relationship between X and
Y is controlled in any way (possibly transitively through a series of
checks performed earlier) and whether we can reasonably infer that the
authorization to watch X implies the ability to be notified of
operations on Y. Not a problem for the mount notifications AFAICS
because there is only truly one object - the mount namespace itself, and
it is always our own.
And for mount notifications, isn't the notification actually for a change to
the mount namespace, not a change to any file?
Yes.
Hence, the real "object" for events that trigger mount notifications is the
mount namespace, right?
Um... arguably. Would that mean that that would need a label from somewhere?
That takes us into the whole question of whether namespaces should be
labeled (presumably from their creator), and the association between
processes and their namespaces should be controlled. I think when we
originally looked at them, it wasn't much of a concern since the only
means of creating a new namespace and associating with it was via
clone() and then later also via unshare(). /proc/pid/ns and setns()
changed that picture, but still requires ptrace read mode access, which
at least provides some control over entering namespaces created by
others. I suspect that ultimately we want namespaces to be labeled and
controlled but that isn't your problem to solve here.
For your purposes, a process is setting a watch on its own namespace,
and it already inherently can observe changes to that namespace without
needing watches/notifications, and it can modify that namespace iff
privileged wrt to the namespace. One might argue that no check is
required at all for setting the watch, and at most, it would be a check
between the process and its own label to match the checking when
accessing /proc/self/mounts. That presumes that no additional
information is conveyed via the notification that isn't already
available from /proc/self/mounts, particularly any information specific
to the process that triggered the notification. Does that make sense?
The watched path is just a way of identifying a subtree of the mount
namespace for notifications - it isn't the real object being watched.
I like that argument.
Thanks,
David
