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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/11/19 10:21 AM, David Howells wrote:
To see if we can try and make progress on this, can we try and come at this
from another angle: what do LSMs *actually* need to do this?  And I grant that
each LSM might require different things.

I think part of the problem here is that the discussion is too abstract and not dealing with the specifics of the notifications in question. Those details matter.


-~-

[A] There are a bunch of things available, some of which may be coincident,
depending on the context:

  (1) The creds of the process that created a watch_queue (ie. opened
      /dev/watch_queue).

These will be used when checking permissions to open /dev/watch_queue.

  (2) The creds of the process that set a watch (ie. called watch_sb,
      KEYCTL_NOTIFY, ...);

These will be used when checking permissions to set a watch.

  (3) The creds of the process that tripped the event (which might be the
      system).

These will be used when checking permission to perform whatever operation tripped the event (if the event is triggered by a userspace operation).

  (4) The security attributes of the object on which the watch was set (uid,
      gid, mode, labels).

These will be used when checking permissions to set the watch.

  (5) The security attributes of the object on which the event was tripped.

These will be used when checking permission to perform whatever operation tripped the event.

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

At the moment, when post_one_notification() wants to write a notification into
a queue, it calls security_post_notification() to ask if it should be allowed
to do so.  This is passed (1) and (3) above plus the notification record.

Not convinced we need this.

[B] There are a number of places I can usefully potentially add hooks:

  (a) The point at which a watch queue is created (ie. /dev/watch_queue is
      opened).

Already covered by existing hooks on opening files.

  (b) The point at which a watch is set (ie. watch_sb).

Yes, this requires a hook and corresponding check.

  (c) The point at which a notification is generated (ie. an automount point is
      tripped).

Preferably covered by existing hooks on object accesses that would generate notifications.

  (d) The point at which a notification is delivered (ie. we write the message
      into the queue).

Preferably not needed.

  (e) All the points at which we walk over an object in a chain from (c) to
      find the watch on which we can effect (d) (eg. we walk rootwards from a
      mountpoint to find watches on a branch in the mount topology).

Not necessary if the real object of mount notifications is the mount namespace and if we do not support recursive notifications on e.g. directories or some other object where the two can truly diverge.

[C] Problems that need to be resolved:

  (x) Do I need to put a security pointer in struct watch for the active LSM to
      fill in?  If so, I presume this would need passing to
      security_post_notification().

I don't see why or where it would get used.

  (y) What checks should be done on object destruction after final put and what
      contexts need to be supplied?

IMHO, no.


      This one is made all the harder because the creds that are in force when
      close(), exit(), exec(), dup2(), etc. close a file descriptor might need
      to be propagated to deferred-fput, which must in turn propagate them to
      af_unix-cleanup, and thence back to deferred-fput and thence to implicit
      unmount (dissolve_on_fput()[*]).

      [*] Though it should be noted that if this happens, the subtree cannot be
      	 attached to the root of a namespace.

      Further, if several processes are sharing a file object, it's not
      predictable as to which process the final notification will come from.

  (z) Do intermediate objects, say in a mount topology notification, actually
      need to be checked against the watcher's creds?  For a mount topology
      notification, would this require calling inode_permission() for each
      intervening directory?

I don't think so, because the real object is the mount namespace, not the individual directories.


      Doing that might be impractical as it would probably have to be done
      outside of of the RCU read lock and the filesystem ->permission() hooks
      might want to sleep (to touch disk or talk to a server).





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux