[PATCH] kobject support for LSM core

[PATCH] kobject support for LSM core

[Petr Baudis]

  Hello,

  the following patch (against 2.5.64) introduces kobject infrastructure
scaffolding to the LSM framework. It does nothing but allocating security root
subsystem for the LSMs, so that they are tied to one specific point in the
kobject hierarchy. They are suggested to create own subsystems under the
security subsystem, however such things are completely up to the individual
LSMs and not regulated by core in any way (it's not that I would so much like
such an approach, but I was advised so by GregKH and it makes sense in its own
way as well).

  A lot of LSMs use various ad hoc methods for communication with the userspace
and using the sysfs framework could be very convient for them, and there is at
least one real-world (altough yet a bit primitive) LSM which already uses the
security subsystem: http://pasky.ji.cz/securitylevels/.

  It works fine for me and it should be pretty trivial. Please consider
applying.

 security/security.c |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+)

  Kind regards,
				Petr Baudis

--- linux/security/security.c	Sun Mar  9 00:40:32 2003
+++ linux+pasky/security/security.c	Thu Mar  6 23:33:49 2003
@@ -9,11 +9,15 @@
  *	it under the terms of the GNU General Public License as published by
  *	the Free Software Foundation; either version 2 of the License, or
  *	(at your option) any later version.
+ *
+ * Introduced kobject infrastructure.
+ * 2003-02-27 Petr Baudis <pasky@ucw.cz>
  */
 
 #include <linux/config.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/kobject.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/security.h>
@@ -38,6 +42,7 @@
 	return 0;
 }
 
+
 /**
  * security_scaffolding_startup - initialzes the security scaffolding framework
  *
@@ -59,6 +64,30 @@
 	return 0;
 }
 
+
+/* kobject stuff */
+
+/* We define only the base subsystem here and leave everything to a LSM. It is
+ * heavily recommended that the LSM should create own subsystem under this one,
+ * so that it can be easily made stackable and it doesn't confuse userland by
+ * exporting its stuff directly to /sys/security/. */
+decl_subsys(security,NULL);
+
+/**
+ * security_kobj_init - initializes the security kobject subsystem
+ *
+ * This is called after security_scaffolding_startup as a regular initcall,
+ * since we need sysfs mounted already.
+ */
+static int __init security_kobj_init (void)
+{
+	subsystem_register (&security_subsys);
+	return 0;
+}
+
+subsys_initcall(security_kobj_init);
+
+
 /**
  * register_security - registers a security framework with the kernel
  * @ops: a pointer to the struct security_options that is to be registered
@@ -197,3 +226,4 @@
 EXPORT_SYMBOL_GPL(mod_unreg_security);
 EXPORT_SYMBOL(capable);
 EXPORT_SYMBOL(security_ops);
+EXPORT_SYMBOL(security_subsys);

Re: [PATCH] kobject support for LSM core

[Greg KH]

On Mon, Mar 10, 2003 at 01:13:10AM +0100, Petr Baudis wrote:
> 
>   the following patch (against 2.5.64) introduces kobject infrastructure
> scaffolding to the LSM framework. It does nothing but allocating security root
> subsystem for the LSMs, so that they are tied to one specific point in the
> kobject hierarchy. They are suggested to create own subsystems under the
> security subsystem, however such things are completely up to the individual
> LSMs and not regulated by core in any way (it's not that I would so much like
> such an approach, but I was advised so by GregKH and it makes sense in its own
> way as well).

Hm, I thought I advised not doing this at all :)

Anyway, if we were to add this, you might want to:

> +
> +/* kobject stuff */
> +
> +/* We define only the base subsystem here and leave everything to a LSM. It is
> + * heavily recommended that the LSM should create own subsystem under this one,
> + * so that it can be easily made stackable and it doesn't confuse userland by
> + * exporting its stuff directly to /sys/security/. */
> +decl_subsys(security,NULL);

Add a prototype of this variable to security.h so that everyone can
actually see it who wants to use it.

> +/**
> + * security_kobj_init - initializes the security kobject subsystem
> + *
> + * This is called after security_scaffolding_startup as a regular initcall,
> + * since we need sysfs mounted already.
> + */
> +static int __init security_kobj_init (void)
> +{
> +	subsystem_register (&security_subsys);
> +	return 0;
> +}
> +
> +subsys_initcall(security_kobj_init);

Why not initialize this when the security core is initialized?  Why
have a new initcall?

And when do you unregister this subsystem?

> +EXPORT_SYMBOL(security_subsys);

No EXPORT_SYMBOL_GPL() for it?  :)

thanks,

greg k-h

[PATCH] kobject support for LSM core (v2)

[Petr Baudis]

Dear diary, on Mon, Mar 10, 2003 at 07:47:38AM CET, I got a letter,
where Greg KH <greg@kroah.com> told me, that...
> On Mon, Mar 10, 2003 at 01:13:10AM +0100, Petr Baudis wrote:
> > 
> >   the following patch (against 2.5.64) introduces kobject infrastructure
> > scaffolding to the LSM framework. It does nothing but allocating security root
> > subsystem for the LSMs, so that they are tied to one specific point in the
> > kobject hierarchy. They are suggested to create own subsystems under the
> > security subsystem, however such things are completely up to the individual
> > LSMs and not regulated by core in any way (it's not that I would so much like
> > such an approach, but I was advised so by GregKH and it makes sense in its own
> > way as well).
> 
> Hm, I thought I advised not doing this at all :)

*mumble* ;-)

> Anyway, if we were to add this, you might want to:
> 
> > +
> > +/* kobject stuff */
> > +
> > +/* We define only the base subsystem here and leave everything to a LSM. It is
> > + * heavily recommended that the LSM should create own subsystem under this one,
> > + * so that it can be easily made stackable and it doesn't confuse userland by
> > + * exporting its stuff directly to /sys/security/. */
> > +decl_subsys(security,NULL);
> 
> Add a prototype of this variable to security.h so that everyone can
> actually see it who wants to use it.

Oops, I accidentally missed that file when diffing, sorry.

> > +/**
> > + * security_kobj_init - initializes the security kobject subsystem
> > + *
> > + * This is called after security_scaffolding_startup as a regular initcall,
> > + * since we need sysfs mounted already.
> > + */
> > +static int __init security_kobj_init (void)
> > +{
> > +	subsystem_register (&security_subsys);
> > +	return 0;
> > +}
> > +
> > +subsys_initcall(security_kobj_init);
> 
> Why not initialize this when the security core is initialized?  Why
> have a new initcall?

See the comment before the function:

+ * since we need sysfs mounted already.

At the time of security_scaffolding_setup(), sysfs is not mounted yet, thus
subsystem_register() returns -EFAULT and is unsuccessful.

> And when do you unregister this subsystem?

Never ;-). Well it appears that there is no need to unregister it explicitly,
at least noone else does it (subsystem_unregister() is called only for
dynamically registered subsystems). If you insist on having it there, I can add
it, but we are following the current way of doing things with leaving it out.

> > +EXPORT_SYMBOL(security_subsys);
> 
> No EXPORT_SYMBOL_GPL() for it?  :)

True, fixed.

The second version of the patch follows...

  Hello,

  the following patch (against 2.5.64) introduces kobject infrastructure
scaffolding to the LSM framework. It does nothing but allocating security root
subsystem for the LSMs, so that they are tied to one specific point in the
kobject hierarchy. They are suggested to create own subsystems under the
security subsystem, however such things are completely up to the individual
LSMs and not regulated by core in any way (it's not that I would so much like
such an approach, but I was advised so by GregKH and it makes sense in its own
way as well).

  A lot of LSMs use various ad hoc methods for communication with the userspace
and using the sysfs framework could be very convient for them, and there is at
least one real-world (altough yet a bit primitive) LSM which already uses the
security subsystem: http://pasky.ji.cz/securitylevels/.

  It works fine for me and it should be pretty trivial. Please consider
applying.

 include/linux/security.h |    2 ++
 security/security.c      |   30 ++++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+)

  Note that this is the second version of the patch, containing changes based
on GregKH's remarks. It fixes missing patch for include/linux/security.h and
exports security_subsys GPL'd.

  Kind regards,
				Petr Baudis

diff -ru linux/security/security.c linux+pasky/security/security.c
--- linux/security/security.c	Sun Mar  9 00:40:32 2003
+++ linux+pasky/security/security.c	Thu Mar 13 00:15:21 2003
@@ -9,11 +9,15 @@
  *	it under the terms of the GNU General Public License as published by
  *	the Free Software Foundation; either version 2 of the License, or
  *	(at your option) any later version.
+ *
+ * Introduced kobject infrastructure.
+ * 2003-02-27 Petr Baudis <pasky@ucw.cz>
  */
 
 #include <linux/config.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/kobject.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/security.h>
@@ -38,6 +42,7 @@
 	return 0;
 }
 
+
 /**
  * security_scaffolding_startup - initialzes the security scaffolding framework
  *
@@ -59,6 +64,30 @@
 	return 0;
 }
 
+
+/* kobject stuff */
+
+/* We define only the base subsystem here and leave everything to a LSM. It is
+ * heavily recommended that the LSM should create own subsystem under this one,
+ * so that it can be easily made stackable and it doesn't confuse userland by
+ * exporting its stuff directly to /sys/security/. */
+decl_subsys(security,NULL);
+
+/**
+ * security_kobj_init - initializes the security kobject subsystem
+ *
+ * This is called after security_scaffolding_startup as a regular initcall,
+ * since we need sysfs mounted already.
+ */
+static int __init security_kobj_init (void)
+{
+	subsystem_register (&security_subsys);
+	return 0;
+}
+
+subsys_initcall(security_kobj_init);
+
+
 /**
  * register_security - registers a security framework with the kernel
  * @ops: a pointer to the struct security_options that is to be registered
@@ -195,5 +224,6 @@
 EXPORT_SYMBOL_GPL(unregister_security);
 EXPORT_SYMBOL_GPL(mod_reg_security);
 EXPORT_SYMBOL_GPL(mod_unreg_security);
+EXPORT_SYMBOL_GPL(security_subsys);
 EXPORT_SYMBOL(capable);
 EXPORT_SYMBOL(security_ops);
diff -ru linux/include/linux/security.h linux+pasky/include/linux/security.h
--- linux/include/linux/security.h	Thu Mar  6 20:31:29 2003
+++ linux+pasky/include/linux/security.h	Thu Mar  6 23:18:46 2003
@@ -22,6 +22,7 @@
 #ifndef __LINUX_SECURITY_H
 #define __LINUX_SECURITY_H
 
+#include <linux/kobject.h>
 #include <linux/fs.h>
 #include <linux/binfmts.h>
 #include <linux/signal.h>
@@ -1745,6 +1746,7 @@
 extern int unregister_security	(struct security_operations *ops);
 extern int mod_reg_security	(const char *name, struct security_operations *ops);
 extern int mod_unreg_security	(const char *name, struct security_operations *ops);
+extern struct subsystem		security_subsys;
 
 
 #else /* CONFIG_SECURITY */

Re: [PATCH] kobject support for LSM core (v2)

[Greg KH]

On Thu, Mar 13, 2003 at 12:20:27AM +0100, Petr Baudis wrote:
> The second version of the patch follows...

Much nicer, and I would agree to add this patch to the kernel, if there
was actually a user for it :)

Mind converting one of the exsting LSM modules to use this sysfs
subsystem?

thanks,

greg k-h

Re: [PATCH] kobject support for LSM core (v2)

[Chris Wright]

* Petr Baudis (pasky@ucw.cz) wrote:
> 
> At the time of security_scaffolding_setup(), sysfs is not mounted yet, thus
> subsystem_register() returns -EFAULT and is unsuccessful.

yup, same problem with the early init patch.

>  A lot of LSMs use various ad hoc methods for communication with the userspace
> and using the sysfs framework could be very convient for them, and there is at

This would be more compelling if you could convert something in the LSM
tree to using it.  Right now, this patch just adds something that is not
clearly needed.  What about converting DTE to use this new subsystem?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net