RFE: introduce LSM specific fanotify flags for the "path_notify" hook

[pcmoore]

From the mailing list:

From: @stephensmalley
To: @WOnder93
Cc: @bachradsusi, SElinux list, @pcmoore
Subject: Re: [RFC PATCH] selinux: runtime disable is deprecated, add some ssleep() discomfort
Date: Thu, 10 Sep 2020 10:54:38 -0400

On Thu, Sep 10, 2020 at 10:36 AM Stephen Smalley wrote:

On Thu, Sep 10, 2020 at 9:31 AM Stephen Smalley wrote:

2. For cases where an error is returned by SELinux that is not already
   governed by a selinux_initialized() or enforcing_enabled() check, we
   just need to ensure that all such cases are gated by such a check. We
   fixed that recently for the removexattr security.selinux case and
   there were some earlier cases fixed with respect to setting labels
   before policy load. The specific concern raised in the thread
   appeared to be due to denials silenced via dontaudit rules, which
   won't happen if there is no policy loaded so I don't think that's
   relevant. There are other cases where SELinux might return an error
   if a new case is introduced in another kernel subsystem without
   updating SELinux to handle it, e.g. a new type for
   selinux_perf_event_open(), a new obj_type in selinux_path_notify().
   It would be better if we could introduce build-time guards to catch
   these as we have done for e.g. new capabilities, new socket address
   families, new netlink message types, in order to ensure that they are
   always in sync.

On second look, selinux_perf_event_open() is ok because the type
values are specifically (and only) for the security hook, so anyone
adding new PERF_SECURITY_* types should see the need to update the
hook implementation too. selinux_path_notify() case is different.

For selinux_path_notify(), there are in fact other fsnotify object
types defined in fsnotify_backend.h but
fs/notify/fanotify_user.c:do_fanotify_mark() only ever sets obj_type
that is later passed to the hook to one of the three values it handles
(inode, vfsmount, sb). Since that could potentially change in the
future, we should likely change the security framework to define its
own set of SECURITY_NOTIFY_OBJ_TYPE_* values and have the hook callers
explicitly translate to one of those.