On Wed, Jan 9, 2019 at 12:08 PM Casey Schaufler [off-list ref] wrote:

On 1/9/2019 8:28 AM, Ondrej Mosnacek wrote:

quoted

This patch introduces a new security hook that is intended for
initializing the security data for newly created pseudo filesystem
objects (such as kernfs nodes) that provide a way of storing a
non-default security context, but need to operate independently from
mounts.

The main motivation is to allow kernfs nodes to inherit the context of
the parent under SELinux, similar to the behavior of
security_inode_init_security(). Other LSMs may implement their own logic
for handling the creation of new nodes.

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
---
 include/linux/lsm_hooks.h | 30 ++++++++++++++++++++++++++++++
 include/linux/security.h  | 14 ++++++++++++++
 security/security.c       | 10 ++++++++++
 3 files changed, 54 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index aaeb7fa24dc4..3a2399d7721f 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h

@@ -429,6 +429,31 @@
  *   to abort the copy up. Note that the caller is responsible for reading
  *   and writing the xattrs as this hook is merely a filter.
  *
+ * Security hooks for special file-like objects
+ *
+ * @object_init_security:

I don't like the name. There are too many things that are "objects"
for this to be meaningful. I also dislike seeing names like
security_object_init_security. How about init_from_parent? If there's
never a chance that it will be used anywhere but with kernfs, it could
be kernfs_node_init. The existing set of hook names are sufficiently
confusing without adding to the mystery.

I like the naming similarity with inode_init_security(), that seems
helpful.  Although I somewhat understand you concern about the generic
"object".  Could you live with kernfs_init_security()?  If another fs
adopts it, we could always changing the name later if needed.

-- 
paul moore
www.paul-moore.com