Re: What do LSMs *actually* need for checks on notifications?

From: Stephen Smalley
Date: Thu Jun 13 2019 - 14:51:27 EST

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?


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.