On Thu, Sep 10, 2020 at 10:36 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Thu, Sep 10, 2020 at 9:31 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> 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.
