Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Adam Jerome]

On Wed, Oct 24, 2007 at  6:55 AM, Adrian Bunk <bunk@kernel.org> wrote: 
> On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
>> I currently have an LSM that only handles permissions for socket_bind
>> and socket_listen, I load it and then "capability" as secondary on
>> boot - but now I can't because the LSM framework is now just the LS
>> framework.
>> 
>> Why can't this "static LSM" change be a Kconfig option?
>> (I don't want to have to maintain my own reverted copy of security/,
>> or compile this into the kernel because then I can't ever modify and
>> reload it without rebooting.)
> 
> Let's start with the more important questions:
> 
> Did you submit your LSM for inclusion into the kernel?
> 
> If yes, why wasn't it accepted?
> If no, why not?

Those are important questions, no doubt.  However, that does not
address Simon's question.  Especially in light of Linus' statement:

 "I'm also perfectly willing to unapply it if there actually are
  valid out-of-tree users that people push for not merging."

It seems that, whether submitted (and or accepted) into the kernel
or not, Simon has the obligation to respond to Linus' challenge.

-adam

Re: LSM conversion to static interface

[Linus Torvalds]

On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> 
> But then I noticed that, while the LSM would remain in existence, it was 
> being closed to out-of-tree security frameworks.  Yikes!  Since then, 
> I've been following the rush to put SMACK, TOMOYO and AppArmor 
> "in-tree".

Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE 
people were ok with it (AppArmor), but I'm with you - I applied it, but 
I'm also perfectly willing to unapply it if there actually are valid 
out-of-tree users that people push for not merging.

So Í don't think this is settled in any way - please keep discussing, and 
bringing it up. I'm definitely not in the camp that thinks that LSM needs 
to be "controlled", but on the other hand, I'm also not going to undo that 
commit unless there are good real arguments for undoing it (not just 
theoretical ones).

For example, I do kind of see the point that a "real" security model might 
want to be compiled-in, and not something you override from a module. Of 
course, I'm personally trying to not use any modules at all, so I'm just 
odd and contrary, so whatever..

Real usage scenarios with LSM modules, please speak up!

		Linus

Re: LSM conversion to static interface

[Andreas Gruenbacher]

On Thursday 18 October 2007 04:18, Linus Torvalds wrote:
> On Wed, 17 Oct 2007, Thomas Fricaccia wrote:
> > 
> > But then I noticed that, while the LSM would remain in existence, it was 
> > being closed to out-of-tree security frameworks.  Yikes!  Since then, 
> > I've been following the rush to put SMACK, TOMOYO and AppArmor 
> > "in-tree".
> 
> Yeah, it did come up. Andrew, when he sent it on to me, said that the SuSE 
> people were ok with it (AppArmor), but I'm with you - I applied it, but 
> I'm also perfectly willing to unapply it if there actually are valid 
> out-of-tree users that people push for not merging.

The patch doesn't hurt AppArmor, but it's still a step in the wrong direction.

Quoting from commit 20510f2f (Convert LSM into a static interface):
> In a nutshell, there is no safe way to unload an LSM.  The modular interface
> is thus unecessary and broken infrastructure.  It is used only by
> out-of-tree modules, which are often binary-only, illegal, abusive of the
> API and dangerous, e.g.  silently re-vectoring SELinux.

This is idiotic. Just because there is no safe way to unload SELinux

 - doesn't mean there is no safe way to unload other LSMs: if nothing
   but that, unloading is handy during development.

 - doesn't mean that module *loading* is unsafe. The patch removes module
   loading as well, which hurts more than removing module unloading.

LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM 
loadable modules have been known to do lots of bad things, and yet nobody 
made them non-loadable either (yet).

> [...]
> For example, I do kind of see the point that a "real" security model might 
> want to be compiled-in, and not something you override from a module.

Non-trivial modules (i.e., practically everything beyond capabilities) become 
effective only after loading policy, anyway. If you can load policy, you can 
as well first load a security module without making the system insecure.

Thanks,
Andreas

Re: LSM conversion to static interface

[Linus Torvalds]

On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
> 
> Non-trivial modules (i.e., practically everything beyond capabilities) become 
> effective only after loading policy, anyway. If you can load policy, you can 
> as well first load a security module without making the system insecure.

I'd like to note that I asked people who were actually affected, and had 
examples of their real-world use to step forward and explain their use, 
and that I explicitly mentioned that this is something we can easily 
re-visit.

But I also note that you did no such thing, neither has anybody else.

The fact is, security people *are* insane. You just argue all the time, 
instead fo doing anything productive. So please don't include me in the Cc 
on your insane arguments - instead do something productive and I'm 
interested.

Ok? That was the whole point of LSM in the first place. I'm *not* 
interested in getting roped into your insane arguments. I'm interested in 
moving forward and having real examples of real use and code. Until then, 
this issue is closed. I thought I had made that clear already, but 
apparently not clear enough.

So I repeat: we can undo that commit, but I will damn well not care one 
whit about yet another pointless security model flamewar.

		Linus

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 19 2007 13:40, Linus Torvalds wrote:
>On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:
>> 
>> Non-trivial modules (i.e., practically everything beyond capabilities) become 
>> effective only after loading policy, anyway. If you can load policy, you can 
>> as well first load a security module without making the system insecure.
>
>I'd like to note that I asked people who were actually affected, and had 
>examples of their real-world use to step forward and explain their use, 
>and that I explicitly mentioned that this is something we can easily 
>re-visit.
>

I do have a pseudo LSM called "multiadm" at 
http://freshmeat.net/p/multiadm/ , quoting:

	The MultiAdmin security framework kernel module provides a means 
	to have multiple "root" users with unique UIDs. This bypasses 
	collation order problems with NSCD, allows you to have files 
	with unique owners, and allows you to track the quota usage for 
	every "real" user. It also implements a "sub-admin", a partially 
	restricted root user who has full read-only access to most 
	subsystems, but write rights only to a limited subset, for 
	example writing to files or killing processes only of certain 
	users.

The use case is so that profs (taking the role of sub-admins), can 
operate on student's data/processes/etc. (quite often needed), but 
without having the full root privileges.

Policy is dead simple since it is based on UIDs. The UID ranges can be 
set on module load time or during runtime (sysfs params). This LSM is 
basically grants extra rights unlike most other LSMs[1], which is why 
modprobe makes much more sense here. (It also does not have to do any 
security labelling that would require it to be loaded at boot time 
already.)

Does that sound productive?


>The fact is, security people *are* insane. You just argue all the time, 
>instead fo doing anything productive. So please don't include me in the Cc 
>on your insane arguments - instead do something productive and I'm 
>interested.

[1] SELinux: What I remember from coker.com.au's selinux test machine, 
everyone had UID 0 and instead had powers revoked.

Re: LSM conversion to static interface

[James Morris]

On Sat, 20 Oct 2007, Jan Engelhardt wrote:

> >I'd like to note that I asked people who were actually affected, and had 
> >examples of their real-world use to step forward and explain their use, 
> >and that I explicitly mentioned that this is something we can easily 
> >re-visit.
> >
> 
> I do have a pseudo LSM called "multiadm" at 
> http://freshmeat.net/p/multiadm/ , quoting:
> 

Based on Linus' criteria, this appears to be a case for reverting the 
static LSM patch.

Jan, I remember you posting this last year and IIRC, there were really 
only coding style issues to be addressed.  There were some review queries 
and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers -- 
certainly not now that security architecture and security model objections 
are out of bounds.

So, I would suggest reposting the code for upstream inclusion, which 
would be better at least in terms of upstream maintenance, as your code 
will be visible in the tree.


- James
-- 
James Morris
<jmorris@namei.org>

Re: LSM conversion to static interface [revert patch]

[Arjan van de Ven]

On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
James Morris <jmorris@namei.org> wrote:

> On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> 
> > >I'd like to note that I asked people who were actually affected,
> > >and had examples of their real-world use to step forward and
> > >explain their use, and that I explicitly mentioned that this is
> > >something we can easily re-visit.
> > >
> > 
> > I do have a pseudo LSM called "multiadm" at 
> > http://freshmeat.net/p/multiadm/ , quoting:
> > 
> 
> Based on Linus' criteria, this appears to be a case for reverting the 
> static LSM patch.

I don't want to argue for or against the actual revert; however if Linus/James/Chris
decide to do a revert, I've made a patch to do that below

(doing a full git revert is tricky since it gets mixed up with various other cleanup 
patches; even inside the original patch. I've done the relevant pieces by hand via a 
selective patch -R and compile-tested it). In addition I've made the modularity a 
Kconfig option, since it's clearly something that is contested and thus is justified 
as a user compile time choice; people who don't want this (out of paranoia or otherwise)
can now decide to disable, while others who want to experiment or use out of tree 
LSM modules, can select the KConfig option.

If it turns out that the above module becomes unmaintained and no longer usable, and no
other useful cases show up, we can always garbage collect this code in the future; it's 
now low-overhead anyway for those who care, due to the KConfig option.

---

From: Arjan van de Ven <arjan@linux.intel.com>
Subject: revert the modular LSM patch

Since there is a real out of tree, non-racey modular LSM module,
add back the capability to have modular LSM modules as a config option.

(note that this patch fails checkpatch.pl in a few places, however
since this is just a reverse-patch of the original code, I don't
want to fix this in order to keep exact revert behavior)


Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>

diff -purN linux-2.6.23-git17/include/linux.org/security.h linux-2.6.23-git17/include/linux/security.h
--- linux-2.6.23-git17/include/linux.org/security.h	2007-10-21 10:35:49.000000000 +0200
+++ linux-2.6.23-git17/include/linux/security.h	2007-10-21 10:36:00.000000000 +0200
@@ -1178,6 +1178,10 @@ struct request_sock;
  * 	allow module stacking.
  * 	@name contains the name of the security module being stacked.
  * 	@ops contains a pointer to the struct security_operations of the module to stack.
+ * @unregister_security:
+ *	remove a stacked module.
+ *	@name contains the name of the security module being unstacked.
+ *	@ops contains a pointer to the struct security_operations of the module to unstack.
  * 
  * @secid_to_secctx:
  *	Convert secid to security context.
@@ -1365,6 +1369,8 @@ struct security_operations {
 	/* allow module stacking */
 	int (*register_security) (const char *name,
 	                          struct security_operations *ops);
+	int (*unregister_security) (const char *name,
+	                            struct security_operations *ops);
 
 	void (*d_instantiate) (struct dentry *dentry, struct inode *inode);
 
@@ -1445,7 +1451,9 @@ struct security_operations {
 /* prototypes */
 extern int security_init	(void);
 extern int register_security	(struct security_operations *ops);
+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 dentry *securityfs_create_file(const char *name, mode_t mode,
 					     struct dentry *parent, void *data,
 					     const struct file_operations *fops);
diff -purN linux-2.6.23-git17/security.org/dummy.c linux-2.6.23-git17/security/dummy.c
--- linux-2.6.23-git17/security.org/dummy.c	2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/dummy.c	2007-10-21 10:36:00.000000000 +0200
@@ -908,6 +908,11 @@ static int dummy_register_security (cons
 	return -EINVAL;
 }
 
+static int dummy_unregister_security (const char *name, struct security_operations *ops)
+{
+	return -EINVAL;
+}
+
 static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode)
 {
 	return;
@@ -1082,6 +1087,7 @@ void security_fixup_ops (struct security
 	set_to_dummy_if_null(ops, netlink_send);
 	set_to_dummy_if_null(ops, netlink_recv);
 	set_to_dummy_if_null(ops, register_security);
+	set_to_dummy_if_null(ops, unregister_security);
 	set_to_dummy_if_null(ops, d_instantiate);
  	set_to_dummy_if_null(ops, getprocattr);
  	set_to_dummy_if_null(ops, setprocattr);
diff -purN linux-2.6.23-git17/security.org/Kconfig linux-2.6.23-git17/security/Kconfig
--- linux-2.6.23-git17/security.org/Kconfig	2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/Kconfig	2007-10-21 10:36:14.000000000 +0200
@@ -51,6 +51,20 @@ config SECURITY
 
 	  If you are unsure how to answer this question, answer N.
 
+config SECURITY_MODULAR
+	bool "Allow loadable security models"
+	depends on SECURITY
+	help
+	  This allows you to load and unload security modules at
+	  runtime.
+
+	  This option is useful for developers of security modules
+	  or for experimenting with security modules that are not in
+	  your kernel (yet). Note that (un)loading security modules
+	  can be a dangerous situation so use with care.
+
+	  If you are unsure how to answer this question, answer N.
+
 config SECURITY_NETWORK
 	bool "Socket and Networking Security Hooks"
 	depends on SECURITY
diff -purN linux-2.6.23-git17/security.org/security.c linux-2.6.23-git17/security/security.c
--- linux-2.6.23-git17/security.org/security.c	2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/security.c	2007-10-21 10:37:41.000000000 +0200
@@ -71,7 +71,8 @@ int __init security_init(void)
  *
  * This function is to allow a security module to register itself with the
  * kernel security subsystem.  Some rudimentary checking is done on the @ops
- * value passed to this function.
+ * value passed to this function.  A call to unregister_security() should be
+ * done to remove this security_options structure from the kernel.
  *
  * If there is already a security module registered with the kernel,
  * an error will be returned.  Otherwise 0 is returned on success.
@@ -121,6 +122,62 @@ int mod_reg_security(const char *name, s
 	return security_ops->register_security(name, ops);
 }
 
+#ifdef CONFIG_SECURITY_MODULAR
+/**
+ * unregister_security - unregisters a security framework with the kernel
+ * @ops: a pointer to the struct security_options that is to be registered
+ *
+ * This function removes a struct security_operations variable that had
+ * previously been registered with a successful call to register_security().
+ *
+ * If @ops does not match the valued previously passed to register_security()
+ * an error is returned.  Otherwise the default security options is set to the
+ * the dummy_security_ops structure, and 0 is returned.
+ */
+int unregister_security(struct security_operations *ops)
+{
+	if (ops != security_ops) {
+		printk(KERN_INFO "%s: trying to unregister "
+		       "a security_opts structure that is not "
+		       "registered, failing.\n", __FUNCTION__);
+		return -EINVAL;
+	}
+
+	security_ops = &dummy_security_ops;
+
+	return 0;
+}
+
+/**
+ * mod_unreg_security - allows a security module registered with mod_reg_security() to be unloaded
+ * @name: a pointer to a string with the name of the security_options to be removed
+ * @ops: a pointer to the struct security_options that is to be removed
+ *
+ * This function allows security modules that have been successfully registered
+ * with a call to mod_reg_security() to be unloaded from the system.
+ * This calls the currently loaded security module's unregister_security() call
+ * with the @name and @ops variables.
+ *
+ * The return value depends on the currently loaded security module, with 0 as
+ * success.
+ */
+int mod_unreg_security(const char *name, struct security_operations *ops)
+{
+	if (ops == security_ops) {
+		printk(KERN_INFO "%s invalid attempt to unregister "
+		       " primary security ops.\n", __FUNCTION__);
+		return -EINVAL;
+	}
+
+	return security_ops->unregister_security(name, ops);
+}
+
+EXPORT_SYMBOL_GPL(register_security);
+EXPORT_SYMBOL_GPL(unregister_security);
+EXPORT_SYMBOL_GPL(mod_reg_security);
+EXPORT_SYMBOL_GPL(mod_unreg_security);
+#endif
+
 /* Security operations */
 
 int security_ptrace(struct task_struct *parent, struct task_struct *child)
diff -purN linux-2.6.23-git17/security.org/selinux/hooks.c linux-2.6.23-git17/security/selinux/hooks.c
--- linux-2.6.23-git17/security.org/selinux/hooks.c	2007-10-21 02:04:21.000000000 +0200
+++ linux-2.6.23-git17/security/selinux/hooks.c	2007-10-21 10:38:27.000000000 +0200
@@ -4549,6 +4549,19 @@ static int selinux_register_security (co
 	return 0;
 }
 
+static int selinux_unregister_security (const char *name, struct security_operations *ops)
+{
+	if (ops != secondary_ops) {
+		printk(KERN_ERR "%s:  trying to unregister a security module "
+		        "that is not registered.\n", __FUNCTION__);
+		return -EINVAL;
+	}
+
+	secondary_ops = original_ops;
+
+	return 0;
+}
+
 static void selinux_d_instantiate (struct dentry *dentry, struct inode *inode)
 {
 	if (inode)
@@ -4895,6 +4908,7 @@ static struct security_operations selinu
 	.sem_semop =			selinux_sem_semop,
 
 	.register_security =		selinux_register_security,
+	.unregister_security =		selinux_unregister_security,
 
 	.d_instantiate =                selinux_d_instantiate,
 

Re: LSM conversion to static interface [revert patch]

[Chris Wright]

* Arjan van de Ven (arjan@infradead.org) wrote:
> On Sun, 21 Oct 2007 08:57:06 +1000 (EST)
> James Morris <jmorris@namei.org> wrote:
> 
> > On Sat, 20 Oct 2007, Jan Engelhardt wrote:
> > 
> > > >I'd like to note that I asked people who were actually affected,
> > > >and had examples of their real-world use to step forward and
> > > >explain their use, and that I explicitly mentioned that this is
> > > >something we can easily re-visit.
> > > >
> > > 
> > > I do have a pseudo LSM called "multiadm" at 
> > > http://freshmeat.net/p/multiadm/ , quoting:
> > > 
> > 
> > Based on Linus' criteria, this appears to be a case for reverting the 
> > static LSM patch.
> 
> I don't want to argue for or against the actual revert; however if Linus/James/Chris
> decide to do a revert, I've made a patch to do that below

Thanks Arjan.  I did not actually oppose making it non-modular, and
thought there was sufficient time for people to complain meaningfully
on that change.  I also think there's not a lot of value in the modular
interface, but it's very difficult to have rational discussions in this
area.

> (doing a full git revert is tricky since it gets mixed up with various other cleanup 
> patches; even inside the original patch. I've done the relevant pieces by hand via a 
> selective patch -R and compile-tested it). In addition I've made the modularity a 
> Kconfig option, since it's clearly something that is contested and thus is justified 
> as a user compile time choice; people who don't want this (out of paranoia or otherwise)
> can now decide to disable, while others who want to experiment or use out of tree 
> LSM modules, can select the KConfig option.
> 
> If it turns out that the above module becomes unmaintained and no longer usable, and no
> other useful cases show up, we can always garbage collect this code in the future; it's 
> now low-overhead anyway for those who care, due to the KConfig option.

Yes, and I think we can still improve performance although I can't see
anyway to help out the modular case, so I guess it will have to incur
the hit that's always been there.  I think your Kconfig option is a
decent compromise.

thanks,
-chris

Re: LSM conversion to static interface [revert patch]

[Jeremy Fitzhardinge]

Chris Wright wrote:
> Yes, and I think we can still improve performance although I can't see
> anyway to help out the modular case, so I guess it will have to incur
> the hit that's always been there.  

Broaden the paravirt patching machinery?

    J

Re: LSM conversion to static interface [revert patch]

[Arjan van de Ven]

On Tue, 23 Oct 2007 17:31:28 -0700
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Chris Wright wrote:
> > Yes, and I think we can still improve performance although I can't
> > see anyway to help out the modular case, so I guess it will have to
> > incur the hit that's always been there.  
> 
> Broaden the paravirt patching machinery?
> 

so far I've something much simpler in mind, I have a first prototype
and it shows code that is pretty much optimal on modern cpus.

I hope to have something postable in a week or so

Linux Security *Module* Framework (Was: LSM conversion to static interface

[Simon Arlott]

I currently have an LSM that only handles permissions for socket_bind
and socket_listen, I load it and then "capability" as secondary on
boot - but now I can't because the LSM framework is now just the LS
framework.

Why can't this "static LSM" change be a Kconfig option?
(I don't want to have to maintain my own reverted copy of security/,
or compile this into the kernel because then I can't ever modify and
reload it without rebooting.)

-- 
Simon Arlott

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Adrian Bunk]

On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
> I currently have an LSM that only handles permissions for socket_bind
> and socket_listen, I load it and then "capability" as secondary on
> boot - but now I can't because the LSM framework is now just the LS
> framework.
> 
> Why can't this "static LSM" change be a Kconfig option?
> (I don't want to have to maintain my own reverted copy of security/,
> or compile this into the kernel because then I can't ever modify and
> reload it without rebooting.)

Let's start with the more important questions:

Did you submit your LSM for inclusion into the kernel?

If yes, why wasn't it accepted?
If no, why not?

> Simon Arlott

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Tetsuo Handa]

Hello.

Simon Arlott wrote:
> I currently have an LSM that only handles permissions for socket_bind
> and socket_listen, I load it and then "capability" as secondary on
> boot - but now I can't because the LSM framework is now just the LS
> framework.

I think there are two other problems regarding LSM.

(1) There is only one "struct security_ops" structure in the system.

(2) There is only one "void *security" field in "struct task_struct".


Years ago, there was only one MAC implementation (i.e. SELinux)
in the mainline kernel.
But now, there are many MAC (or access control/tracking) implementations
waiting for inclusion into the mainline kernel.
The competition for occupying "struct security_ops" has started.

My idea is that, why not create chains of "struct security_ops"
(i.e. linked list of "struct security_ops")
and allow choosing which chain to use for per a "struct task_struct" basis
(i.e. add "struct security_ops" to "struct task_struct").

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
"struct security_ops" since SELinux is occupying it.
Yes, there is secondary_ops in SELinux, but it doesn't help TOMOYO Linux
since SELinux is not calling secondary ops for operations TOMOYO Linux wants to control.
So, there is only one "struct security_ops" as a matter of practice.


At the same time, the competition for occupying "void *security" has started.

My idea is that, why not allow multiple "void *security" fields in "struct task_struct"?

TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
"struct task_struct"->security field since SELinux is occupying it.
If TOMOYO Linux is permitted to add "void *" and "u32" to "struct task_struct",
SELinux and other LSM implementations can use "struct task_struct"->security field.


May be we should consider stackable LSM again?

Regards.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface

[Crispin Cowan]

Tetsuo Handa wrote:
> I think there are two other problems regarding LSM.
>
> (1) There is only one "struct security_ops" structure in the system.
>
> (2) There is only one "void *security" field in "struct task_struct".
>
>
> Years ago, there was only one MAC implementation (i.e. SELinux)
> in the mainline kernel.
> But now, there are many MAC (or access control/tracking) implementations
> waiting for inclusion into the mainline kernel.
> The competition for occupying "struct security_ops" has started.
>
> My idea is that, why not create chains of "struct security_ops"
> (i.e. linked list of "struct security_ops")
> and allow choosing which chain to use for per a "struct task_struct" basis
> (i.e. add "struct security_ops" to "struct task_struct").
>   
That idea was in the Stacker module, and it was tabled until there is
more than one upstream LSM. In particular, it requires 2 or more LSMs
that actually make sense to stack together. IMHO TOMOYO/AppArmor/SELinux
are all exclusive of one another (in a running kernel) and real stacking
is still pending useful component intrusion prevention modules. Such
modules can be built, they just have not yet been built.

> TOMOYO Linux is having difficulty that TOMOYO Linux unlikely be able to use
> "struct security_ops" since SELinux is occupying it.
>   
Just disable SELinux and load TOMOYO. Oh, you can't because someone has
made modules not be loadable :(  Hmmm, perhaps someone could fix that by
reverting the static interface patch ... :)

> May be we should consider stackable LSM again?
>   
Exactly. Stacker was shelved, so to speak :) because of the lack of
in-kernel modules. Soon it will be time to reconsider that.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work