Re: LSM conversion to static interface

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

[Adrian Bunk]

On Sun, Oct 21, 2007 at 08:57:06AM +1000, James Morris 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.
>...

If you take it that strictly, the in-kernel root_plug LSM could have 
been considered enough reason for reverting...

The interesting question is IMHO still:

Were Greg and Jan the only people to write such LSMs, or how many 
non-abusive users that make sense as modules do really exist after
5 years?

Either you can count such real-world users with your fingers or there's 
a reason why these modules didn't get included.

IOW:
Either the API has proven to not attract enough modular users or we are 
having a to-be-fixed problem with getting the LSMs submitted and 
included.

> - James

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: 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]

[James Morris]

On Mon, 22 Oct 2007, Arjan van de Ven wrote:

> @@ -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,

You also need to consider whether to allow capabilities to be built as an 
unloadable module.  If not, then we don't need this hook added back into 
SELinux.  Otherwise, if it is desired, you also need to reinstate 
capability_exit and general modular bits for security/capability.c.


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

Re: LSM conversion to static interface [revert patch]

[Arjan van de Ven]

On Tue, 23 Oct 2007 14:56:52 +1000 (EST)
James Morris <jmorris@namei.org> wrote:

> On Mon, 22 Oct 2007, Arjan van de Ven wrote:
> 
> > @@ -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,
> 
> You also need to consider whether to allow capabilities to be built
> as an unloadable module.  If not, then we don't need this hook added
> back into SELinux.  Otherwise, if it is desired, you also need to
> reinstate capability_exit and general modular bits for
> security/capability.c.
> 

this just allows 3d party replacements of capability like functions;
there is no need/point to have the existing capability back as modular
to be honest.

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]

[Jan Engelhardt]

On Oct 22 2007 22:16, Chris Wright wrote:
>> 
>> 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.

(Un)registering security modules is a one-time hit. You do not load
and unload modules on a per-minute basis outside debugging.

Re: LSM conversion to static interface [revert patch]

[Chris Wright]

* Jan Engelhardt (jengelh@computergmbh.de) wrote:
> On Oct 22 2007 22:16, 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.  I think your Kconfig option is a
> >decent compromise.
> 
> (Un)registering security modules is a one-time hit. You do not load
> and unload modules on a per-minute basis outside debugging.

I'm referring to the hit for indirect calls

Re: LSM conversion to static interface [revert patch]

[Jan Engelhardt]

On Oct 23 2007 02:13, Chris Wright wrote:
>* Jan Engelhardt (jengelh@computergmbh.de) wrote:
>> On Oct 22 2007 22:16, 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.  I think your Kconfig option is a
>> >decent compromise.
>> 
>> (Un)registering security modules is a one-time hit. You do not load
>> and unload modules on a per-minute basis outside debugging.
>
>I'm referring to the hit for indirect calls

Indeed, I just seen that. Not too nice :(

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]

[Chris Wright]

* 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?

Yup, that's essentially what we've been talking about.

thanks,
-chris

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)

[Simon Arlott]

On 24/10/07 13:55, Adrian Bunk 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?

No, because the interface for configuring it would be rejected... I have 
a /proc file which I write a binary configuration file to. This works 
fine for me but it would take a lot of work to write a proper interface 
- which I'm still not sure how to do*.

That doesn't solve the problem that it's no longer possible to reload LSM 
modules to make changes at runtime. Why should I have to reboot to change 
something from now on when it works ok? The reasoning seems to be based 
around a dislike of some out of tree modules. (Although it doesn't look 
like there's appropriate locking around the register/unregister process.)


* (I've got a list of access rules which are scanned in order until one of 
them matches, and an array of one bit for every port for per-port default 
allow/deny - although the latter could be removed.
http://svn.lp0.eu/simon/portac/trunk/)

-- 
Simon Arlott

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

[Jan Engelhardt]

On Oct 24 2007 19:11, Simon Arlott wrote:
>
>* (I've got a list of access rules which are scanned in order until one of 
>them matches, and an array of one bit for every port for per-port default 
>allow/deny - although the latter could be removed.
>http://svn.lp0.eu/simon/portac/trunk/)

Besides the 'feature' of inhibiting port binding,
is not this task of blocking connections something for a firewall?

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

[Simon Arlott]

On 24/10/07 19:51, Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>>
>>* (I've got a list of access rules which are scanned in order until one of 
>>them matches, and an array of one bit for every port for per-port default 
>>allow/deny - although the latter could be removed.
>>http://svn.lp0.eu/simon/portac/trunk/)
> 
> Besides the 'feature' of inhibiting port binding,
> is not this task of blocking connections something for a firewall?

The firewall blocks incoming connections where appropriate, yes, but it 
doesn't stop one user binding to a port that another user expected to be able 
to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
below 1024 and it's useful to be able to prevent users from binding to them 
too.

-- 
Simon Arlott

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

[Jan Engelhardt]

On Oct 24 2007 19:59, Simon Arlott wrote:
>On 24/10/07 19:51, Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>>
>>>* (I've got a list of access rules which are scanned in order until one of 
>>>them matches, and an array of one bit for every port for per-port default 
>>>allow/deny - although the latter could be removed.
>>>http://svn.lp0.eu/simon/portac/trunk/)
>> 
>> Besides the 'feature' of inhibiting port binding,
>> is not this task of blocking connections something for a firewall?
>
>The firewall blocks incoming connections where appropriate, yes, but it 
>doesn't stop one user binding to a port that another user expected to be able 
>to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
>CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
>below 1024 and it's useful to be able to prevent users from binding to them 
>too.

Indeed.


There has been a feature in the security framework that probably did
not get much attention. It looks like YAGNI first, but on a closer look,
it becomes useful pretty quick - secondary_register.

As more and more simple LSM plugins pop up, stacking/chaining by means
of secondary_register becomes attractive again, especially if these LSMs
target different actions. This is probably the most useful thing why
the LSM interface should remain modular:

# Secure my files
modprobe apparmor
# -*- assuming apparmor implemented secondaries -*-
# Secure my ports
modprobe portac
# More rights to users
modprobe multiadm
# -*- whatever else comes along -*-

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

[David P. Quigley]

On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 19:59, Simon Arlott wrote:
> >On 24/10/07 19:51, Jan Engelhardt wrote:
> >> On Oct 24 2007 19:11, Simon Arlott wrote:
> >>>
> >>>* (I've got a list of access rules which are scanned in order until one of 
> >>>them matches, and an array of one bit for every port for per-port default 
> >>>allow/deny - although the latter could be removed.
> >>>http://svn.lp0.eu/simon/portac/trunk/)
> >> 
> >> Besides the 'feature' of inhibiting port binding,
> >> is not this task of blocking connections something for a firewall?
> >
> >The firewall blocks incoming connections where appropriate, yes, but it 
> >doesn't stop one user binding to a port that another user expected to be able 
> >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
> >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
> >below 1024 and it's useful to be able to prevent users from binding to them 
> >too.
> 
> Indeed.
> 
> 
> There has been a feature in the security framework that probably did
> not get much attention. It looks like YAGNI first, but on a closer look,
> it becomes useful pretty quick - secondary_register.
> 
> As more and more simple LSM plugins pop up, stacking/chaining by means
> of secondary_register becomes attractive again, especially if these LSMs
> target different actions. This is probably the most useful thing why
> the LSM interface should remain modular:
> 
> # Secure my files
> modprobe apparmor
> # -*- assuming apparmor implemented secondaries -*-
> # Secure my ports
> modprobe portac
> # More rights to users
> modprobe multiadm
> # -*- whatever else comes along -*-

There is an issue that you overlook here and it is the successful
composition of security models. While your idea is appealing it presents
several problems. In your example you have 3 models with 3 policies.
AppArmor which has its own port security mechanisms is a MAC model that
from what I have seen appears to have a targeted least privilege policy.
This means that AppArmor picks applications it wishes to secure and
makes sure it can't do anything except what it needs to get its job
done. Your module multiadm takes a user which is completely orthogonal
to the concepts that AppArmor uses and gives him extra privileges. From
what I have read and correct me if I am wrong portac deals with users
instead of programs. Now lets try to reconcile this in a way that is
sane to the user/administrator.

Apparmor wants to lock down some application, it gives the application
access to a particular port, and the minimal set of privileges needed to
execute the application. Since Apparmor is "easy to use" (note the
quotes are to indicate they aren't my words not sarcasm) and SUSE comes
with a targeted policy the user isn't concerned with it. Now multiadm
comes along and an administrator wishes to grant extra rights to a user.
This is fine with multiadm alone since it is the main security module,
however we now have to compose this with AppArmor. So an administrator
runs into an error running his application. Is this because his user
isn't granted the proper escalated privileges? Is it because AppArmor
needs an extra rule to run the application?  It could also be that our
third module has blocked the application because it determined that even
though multiadm specified that the user should have the elevated
privileges to run the application that user shouldn't be able to bind to
that port. 

There might be a better example to illustrate the problem however, this
simple example shows the interdependency of three seemingly simple
modules. Imagine what happens when people really let loose and implement
all sorts of crazy ideas and stack them on top of each other. Stacking
works in things such as file systems because we have a clearly defined
interface with fixed solid semantics. You could attempt to do that but
once you have modules that step on each others toes you have to figure
out a way to reconcile that. It seems to me that you're going to
introduce usability problems that are hard to deal with.

Dave Quigley

> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Serge E. Hallyn]

Quoting David P. Quigley (dpquigl@tycho.nsa.gov):
> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules which are scanned in order until one of 
> > >>>them matches, and an array of one bit for every port for per-port default 
> > >>>allow/deny - although the latter could be removed.
> > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > >> 
> > >> Besides the 'feature' of inhibiting port binding,
> > >> is not this task of blocking connections something for a firewall?
> > >
> > >The firewall blocks incoming connections where appropriate, yes, but it 
> > >doesn't stop one user binding to a port that another user expected to be able 
> > >to use. "Ownership" of ports (1-1023) shouldn't be something only root (via 
> > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports 
> > >below 1024 and it's useful to be able to prevent users from binding to them 
> > >too.
> > 
> > Indeed.
> > 
> > 
> > There has been a feature in the security framework that probably did
> > not get much attention. It looks like YAGNI first, but on a closer look,
> > it becomes useful pretty quick - secondary_register.
> > 
> > As more and more simple LSM plugins pop up, stacking/chaining by means
> > of secondary_register becomes attractive again, especially if these LSMs
> > target different actions. This is probably the most useful thing why
> > the LSM interface should remain modular:
> > 
> > # Secure my files
> > modprobe apparmor
> > # -*- assuming apparmor implemented secondaries -*-
> > # Secure my ports
> > modprobe portac
> > # More rights to users
> > modprobe multiadm
> > # -*- whatever else comes along -*-
> 
> There is an issue that you overlook here and it is the successful
> composition of security models. While your idea is appealing it presents
> several problems. In your example you have 3 models with 3 policies.
> AppArmor which has its own port security mechanisms is a MAC model that
> from what I have seen appears to have a targeted least privilege policy.
> This means that AppArmor picks applications it wishes to secure and
> makes sure it can't do anything except what it needs to get its job
> done. Your module multiadm takes a user which is completely orthogonal
> to the concepts that AppArmor uses and gives him extra privileges. From
> what I have read and correct me if I am wrong portac deals with users
> instead of programs. Now lets try to reconcile this in a way that is
> sane to the user/administrator.
> 
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port. 
> 
> There might be a better example to illustrate the problem however, this

The scariest thing to consider is programs which don't appropriately
handle failure.  So I don't know, maybe the system runs a remote logger
to which the multiadm policy gives some extra privs, but now the portac
module prevents it from sending its data.  And maybe, since the authors
never saw this failure as possible, the program happens to dump
sensitive data in a public readable place.  I *could* be more vague but
it'd be tough :)  But you get the idea.

Or, a better example, a privileged program reads some sensitive data -
as allowed by multiadm, writes it to a file, but apparmor prevented it
from chowning the file to the right user before writing, the program
kept writing anyway, and now the calling user hallyn, rather than the
privileged user sensitive_log_t, owns the file.

I ran into examples of this with the stacker module.  For instance
suddenly the capability module had to be changed so that it would allow
selinux xattrs to be written - leaving that arbitration to selinux.
That hadn't been necessary before since selinux simply didn't explicitly
call the secondary->inode_setxattr() hook.

Note I'm not arguing for or against, only arguing for caution :)

-serge

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

[Jan Engelhardt]

On Oct 24 2007 16:37, Serge E. Hallyn wrote:
>
>Or, a better example, a privileged program reads some sensitive data -
>as allowed by multiadm, writes it to a file, but apparmor prevented it
>from chowning the file to the right user before writing,

Interesting find, I should pay attention to that :-)

But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
the next LSM's function. No one (just a minimal grep in
linux-2.6/security/) besides SELinux does that today. So
while you could load AppArmor ontop of MultiAdm, it would never
be invoked. This is what is known as "sufficient" in PAM parlance.
SELinux OTOH is in "required" mode [again PAM-speak].

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

[David P. Quigley]

On Wed, 2007-10-24 at 23:51 +0200, Jan Engelhardt wrote:
> On Oct 24 2007 16:37, Serge E. Hallyn wrote:
> >
> >Or, a better example, a privileged program reads some sensitive data -
> >as allowed by multiadm, writes it to a file, but apparmor prevented it
> >from chowning the file to the right user before writing,
> 
> Interesting find, I should pay attention to that :-)
> 
> But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
> the next LSM's function. No one (just a minimal grep in
> linux-2.6/security/) besides SELinux does that today. So
> while you could load AppArmor ontop of MultiAdm, it would never
> be invoked. This is what is known as "sufficient" in PAM parlance.
> SELinux OTOH is in "required" mode [again PAM-speak].

True but if we are talking about a true stackable architecture calling
down to your lower component shouldn't be an option it should be a
requirement of the semantics. I would hate to think some module which is
a subset of the restrictiveness of another could override it because its
"sufficient". If that was the case I could load in a module which just
returns 0 for everything and make it "sufficient" bypassing every other
module. This also introduces ordering dependencies. If you install
MultiAdm before AppArmor or SELinux and make it "sufficient" then you
defeated the point of having AppArmor or SELinux installed in the first
place. 

Dave

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Jan Engelhardt]

On Oct 24 2007 18:02, David P. Quigley wrote:
>> 
>> But an LSM needs to _explicitly_ call the next LSM's function. No
>> one (just a minimal grep in linux-2.6/security/) besides SELinux
>> does that today. So while you could load AppArmor ontop of
>> MultiAdm, it would never be invoked. This is what is known as
>> "sufficient" in PAM parlance.
>
>I would hate to think some module which is a subset of the
>restrictiveness of another could override it because its
>"sufficient". If that was the case I could load in a module which
>just returns 0 for everything and make it "sufficient" bypassing
>every other module. This also introduces ordering dependencies. If
>you install MultiAdm before AppArmor or SELinux and make it
>"sufficient" then you defeated the point of having AppArmor or
>SELinux installed in the first place.

If I had to run mtadm and aa alongside each other, I would put aa
into the "secondary" LSM slot.

A number of people have said by now that LSM is supposed to be a
restrict-my-rights block of code. As such, I would put the special,
tiny, give-me-rights code at the front so that it be executed first.
This is what would be intended with mtadm. It really just gives you a
few caps when switching to UID 900 (or whatever), just as Linux
traditionally gives you full caps when switching to UID 0 (e.g. by
executing setuid files). From there on, it is just restrictions, and
the order in which LSMs restrict your actions is probably not so
important as long as they do restrict it.

Thankfully, Linux capabilities are so strangely designed that they
actually become useful - they give you so much power that you _can_
only restrict things afterwards again :-)

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

[david]

On Wed, 24 Oct 2007, Serge E. Hallyn wrote:

> The scariest thing to consider is programs which don't appropriately
> handle failure.  So I don't know, maybe the system runs a remote logger
> to which the multiadm policy gives some extra privs, but now the portac
> module prevents it from sending its data.  And maybe, since the authors
> never saw this failure as possible, the program happens to dump
> sensitive data in a public readable place.  I *could* be more vague but
> it'd be tough :)  But you get the idea.
>
> Or, a better example, a privileged program reads some sensitive data -
> as allowed by multiadm, writes it to a file, but apparmor prevented it
> from chowning the file to the right user before writing, the program
> kept writing anyway, and now the calling user hallyn, rather than the
> privileged user sensitive_log_t, owns the file.
>
> I ran into examples of this with the stacker module.  For instance
> suddenly the capability module had to be changed so that it would allow
> selinux xattrs to be written - leaving that arbitration to selinux.
> That hadn't been necessary before since selinux simply didn't explicitly
> call the secondary->inode_setxattr() hook.
>
> Note I'm not arguing for or against, only arguing for caution :)

this sort of problem is possible with just a single LSM.

remember that unix doesn't try to make it impossible for the system owner 
to hang himself, becouse there are many other cases where the rope is used 
productivly. don't let the possibility that things can be done wrong 
prevent other people from being creative in ways that you never thought 
of.

David Lang

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

[Kyle Moffett]

On Oct 24, 2007, at 17:37:04, Serge E. Hallyn wrote:
> The scariest thing to consider is programs which don't  
> appropriately handle failure.  So I don't know, maybe the system  
> runs a remote logger to which the multiadm policy gives some extra  
> privs, but now the portac module prevents it from sending its  
> data.  And maybe, since the authors never saw this failure as  
> possible, the program happens to dump sensitive data in a public  
> readable place.  I *could* be more vague but it'd be tough :)  But  
> you get the idea.

Well, there *was* that problem with sendmail where it did not  
properly check the result of setuid() and just assumed it had  
succeeded.  So instead of running as "smtpd" it was running as  
"root".   Not a happy memory.

Cheers,
Kyle Moffett

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

[Jan Engelhardt]

On Oct 24 2007 17:02, David P. Quigley wrote:
>> 
>> There has been a feature in the security framework that probably did
>> not get much attention. It looks like YAGNI first, but on a closer look,
>> it becomes useful pretty quick - secondary_register.
>> 
>> As more and more simple LSM plugins pop up, stacking/chaining by means
>> of secondary_register becomes attractive again, especially if these LSMs
>> target different actions. This is probably the most useful thing why
>> the LSM interface should remain modular:
>> 
>> # Secure my files
>> modprobe apparmor
>> # -*- assuming apparmor implemented secondaries -*-
>> # Secure my ports
>> modprobe portac
>> # More rights to users
>> modprobe multiadm
>> # -*- whatever else comes along -*-

>Apparmor wants to lock down some application, it gives the application
>access to a particular port, and the minimal set of privileges needed to
>execute the application. [...]
>however we now have to compose this with AppArmor. So an administrator
>runs into an error running his application. Is this because his user
>isn't granted the proper escalated privileges? Is it because AppArmor
>needs an extra rule to run the application?

Of course, the example I gave assumed that each LSM had disjunctive
features. Apparmor is primarily known for blocking file access,
and portac for blocking bind(2). If one of these gets additionaly
functionality, it would be nice that code gets combined so that
tracking down the piece of code that caused a particular syscall to
say nay is easier to pinpoint.

>It could also be that our third module has blocked the application
>because it determined that even though multiadm specified that the
>user should have the elevated privileges to run the application that
>user shouldn't be able to bind to that port.
>[...] Stacking works in things such as file systems because we have
>a clearly defined interface with fixed solid semantics. You could
>attempt to do that but once you have modules that step on each
>others toes you have to figure out a way to reconcile that.

I agree - if one does not get the magic behind LSM stacking, s/he
should not use it, or learn to use it.
However, if you grasp how it works (probably even easier to learn
than figuring out how to selinux), one should know that a pam_deny.so
even after a pam_permit.so will lock you down. Yeah, it's like PAM
stacking.

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

[Casey Schaufler]

--- "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote:

> On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > On Oct 24 2007 19:59, Simon Arlott wrote:
> > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > >>>
> > >>>* (I've got a list of access rules which are scanned in order until one
> of 
> > >>>them matches, and an array of one bit for every port for per-port
> default 
> > >>>allow/deny - although the latter could be removed.
> > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > >> 
> > >> Besides the 'feature' of inhibiting port binding,
> > >> is not this task of blocking connections something for a firewall?
> > >
> > >The firewall blocks incoming connections where appropriate, yes, but it 
> > >doesn't stop one user binding to a port that another user expected to be
> able 
> > >to use. "Ownership" of ports (1-1023) shouldn't be something only root
> (via 
> > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> 
> > >below 1024 and it's useful to be able to prevent users from binding to
> them 
> > >too.
> > 
> > Indeed.
> > 
> > 
> > There has been a feature in the security framework that probably did
> > not get much attention. It looks like YAGNI first, but on a closer look,
> > it becomes useful pretty quick - secondary_register.
> > 
> > As more and more simple LSM plugins pop up, stacking/chaining by means
> > of secondary_register becomes attractive again, especially if these LSMs
> > target different actions. This is probably the most useful thing why
> > the LSM interface should remain modular:
> > 
> > # Secure my files
> > modprobe apparmor
> > # -*- assuming apparmor implemented secondaries -*-
> > # Secure my ports
> > modprobe portac
> > # More rights to users
> > modprobe multiadm
> > # -*- whatever else comes along -*-
> 
> There is an issue that you overlook here and it is the successful
> composition of security models. While your idea is appealing it presents
> several problems. In your example you have 3 models with 3 policies.
> AppArmor which has its own port security mechanisms is a MAC model that
> from what I have seen appears to have a targeted least privilege policy.
> This means that AppArmor picks applications it wishes to secure and
> makes sure it can't do anything except what it needs to get its job
> done. Your module multiadm takes a user which is completely orthogonal
> to the concepts that AppArmor uses and gives him extra privileges. From
> what I have read and correct me if I am wrong portac deals with users
> instead of programs. Now lets try to reconcile this in a way that is
> sane to the user/administrator.
> 
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port. 
> 
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.
> 
> Dave Quigley

Two very important things to consider:

The LSM is designed to be a restrictive mechanism. An LSM module
is not allowed to grant access that would be denied by usual
mechanisms. There are composition problems, but nothing that is
worse than the problems you have to deal with when a filesystem
is mounted read-only. True, one LSM module could muck with the
data used by another, but that's something you can do today with
setxattr() calls in an application.

Which brings up the second important point. The argument above
has nothing whatever to do with mechanisms provided by the kernel
and everything to do with the privileged applications used to
administer a system. Those applications need to be written so as
to deal properly with unexpected access failures, such as might
be induced by a filesystem mounted read-only or being full. I
am aware of the Holy Grail of a security package that does not
interfere with the operation of "normal" administration. How close
you can come to that in independent of wether your kernel is
an integrated "security solution" or a collection of composed
modules.

This discussion is amazingly disconnected from the issues of LSM.


Casey Schaufler
casey@schaufler-ca.com

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

[David P. Quigley]

On Wed, 2007-10-24 at 14:58 -0700, Casey Schaufler wrote:
> --- "David P. Quigley" <dpquigl@tycho.nsa.gov> wrote:
> 
> > On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote:
> > > On Oct 24 2007 19:59, Simon Arlott wrote:
> > > >On 24/10/07 19:51, Jan Engelhardt wrote:
> > > >> On Oct 24 2007 19:11, Simon Arlott wrote:
> > > >>>
> > > >>>* (I've got a list of access rules which are scanned in order until one
> > of 
> > > >>>them matches, and an array of one bit for every port for per-port
> > default 
> > > >>>allow/deny - although the latter could be removed.
> > > >>>http://svn.lp0.eu/simon/portac/trunk/)
> > > >> 
> > > >> Besides the 'feature' of inhibiting port binding,
> > > >> is not this task of blocking connections something for a firewall?
> > > >
> > > >The firewall blocks incoming connections where appropriate, yes, but it 
> > > >doesn't stop one user binding to a port that another user expected to be
> > able 
> > > >to use. "Ownership" of ports (1-1023) shouldn't be something only root
> > (via 
> > > >CAP_NET_BIND_SERVICE) has. Lots of services also don't have standard ports
> > 
> > > >below 1024 and it's useful to be able to prevent users from binding to
> > them 
> > > >too.
> > > 
> > > Indeed.
> > > 
> > > 
> > > There has been a feature in the security framework that probably did
> > > not get much attention. It looks like YAGNI first, but on a closer look,
> > > it becomes useful pretty quick - secondary_register.
> > > 
> > > As more and more simple LSM plugins pop up, stacking/chaining by means
> > > of secondary_register becomes attractive again, especially if these LSMs
> > > target different actions. This is probably the most useful thing why
> > > the LSM interface should remain modular:
> > > 
> > > # Secure my files
> > > modprobe apparmor
> > > # -*- assuming apparmor implemented secondaries -*-
> > > # Secure my ports
> > > modprobe portac
> > > # More rights to users
> > > modprobe multiadm
> > > # -*- whatever else comes along -*-
> > 
> > There is an issue that you overlook here and it is the successful
> > composition of security models. While your idea is appealing it presents
> > several problems. In your example you have 3 models with 3 policies.
> > AppArmor which has its own port security mechanisms is a MAC model that
> > from what I have seen appears to have a targeted least privilege policy.
> > This means that AppArmor picks applications it wishes to secure and
> > makes sure it can't do anything except what it needs to get its job
> > done. Your module multiadm takes a user which is completely orthogonal
> > to the concepts that AppArmor uses and gives him extra privileges. From
> > what I have read and correct me if I am wrong portac deals with users
> > instead of programs. Now lets try to reconcile this in a way that is
> > sane to the user/administrator.
> > 
> > Apparmor wants to lock down some application, it gives the application
> > access to a particular port, and the minimal set of privileges needed to
> > execute the application. Since Apparmor is "easy to use" (note the
> > quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> > with a targeted policy the user isn't concerned with it. Now multiadm
> > comes along and an administrator wishes to grant extra rights to a user.
> > This is fine with multiadm alone since it is the main security module,
> > however we now have to compose this with AppArmor. So an administrator
> > runs into an error running his application. Is this because his user
> > isn't granted the proper escalated privileges? Is it because AppArmor
> > needs an extra rule to run the application?  It could also be that our
> > third module has blocked the application because it determined that even
> > though multiadm specified that the user should have the elevated
> > privileges to run the application that user shouldn't be able to bind to
> > that port. 
> > 
> > There might be a better example to illustrate the problem however, this
> > simple example shows the interdependency of three seemingly simple
> > modules. Imagine what happens when people really let loose and implement
> > all sorts of crazy ideas and stack them on top of each other. Stacking
> > works in things such as file systems because we have a clearly defined
> > interface with fixed solid semantics. You could attempt to do that but
> > once you have modules that step on each others toes you have to figure
> > out a way to reconcile that. It seems to me that you're going to
> > introduce usability problems that are hard to deal with.
> > 
> > Dave Quigley
> 
> Two very important things to consider:
> 
> The LSM is designed to be a restrictive mechanism. An LSM module
> is not allowed to grant access that would be denied by usual
> mechanisms. There are composition problems, but nothing that is
> worse than the problems you have to deal with when a filesystem
> is mounted read-only. True, one LSM module could muck with the
> data used by another, but that's something you can do today with
> setxattr() calls in an application.
> 
> Which brings up the second important point. The argument above
> has nothing whatever to do with mechanisms provided by the kernel
> and everything to do with the privileged applications used to
> administer a system. Those applications need to be written so as
> to deal properly with unexpected access failures, such as might
> be induced by a filesystem mounted read-only or being full. I
> am aware of the Holy Grail of a security package that does not
> interfere with the operation of "normal" administration. How close
> you can come to that in independent of wether your kernel is
> an integrated "security solution" or a collection of composed
> modules.
> 
> This discussion is amazingly disconnected from the issues of LSM.

This branch of the tree seems to have gone in a direction similar to the
stackable netfilter like architecture that was suggested by someone last
time this came up.

> 
> 
> Casey Schaufler
> casey@schaufler-ca.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Simon Arlott]

On Wed, October 24, 2007 22:02, David P. Quigley wrote:
> Apparmor wants to lock down some application, it gives the application
> access to a particular port, and the minimal set of privileges needed to
> execute the application. Since Apparmor is "easy to use" (note the
> quotes are to indicate they aren't my words not sarcasm) and SUSE comes
> with a targeted policy the user isn't concerned with it. Now multiadm
> comes along and an administrator wishes to grant extra rights to a user.
> This is fine with multiadm alone since it is the main security module,
> however we now have to compose this with AppArmor. So an administrator
> runs into an error running his application. Is this because his user
> isn't granted the proper escalated privileges? Is it because AppArmor
> needs an extra rule to run the application?  It could also be that our
> third module has blocked the application because it determined that even
> though multiadm specified that the user should have the elevated
> privileges to run the application that user shouldn't be able to bind to
> that port.
>
> There might be a better example to illustrate the problem however, this
> simple example shows the interdependency of three seemingly simple
> modules. Imagine what happens when people really let loose and implement
> all sorts of crazy ideas and stack them on top of each other. Stacking
> works in things such as file systems because we have a clearly defined
> interface with fixed solid semantics. You could attempt to do that but
> once you have modules that step on each others toes you have to figure
> out a way to reconcile that. It seems to me that you're going to
> introduce usability problems that are hard to deal with.

I agree that it can cause problems, but it's up to the modules themselves
to determine how to combine permissions with their immediate secondary
module.

Instead we now have a static LSM where combining features from one module
means duplicating it in another - then when two modules contain most of
the other's code, but perhaps vastly different configuration mechanisms,
someone will propose removing one of the two...

-- 
Simon Arlott

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

[Crispin Cowan]

Jan Engelhardt wrote:
> On Oct 24 2007 19:11, Simon Arlott wrote:
>   
>> * (I've got a list of access rules which are scanned in order until one of 
>> them matches, and an array of one bit for every port for per-port default 
>> allow/deny - although the latter could be removed.
>> http://svn.lp0.eu/simon/portac/trunk/)
>>     
> Besides the 'feature' of inhibiting port binding,
> is not this task of blocking connections something for a firewall?
>   
So now you are criticizing his module. Arguing about the merits of
security semantics. This is exactly why Linus wanted LSM, so we don't
have to have these kinds of discussions, at least not on LKML :)

It seems to me that LSM used to be an open API. Anyone could code to it,
so you could at least try to ship a module that will load into a major
vendor's stock kernel for an important release.

Now with this change, it is effectively a closed API. You can only load
the modules that the distro vendor shipped to you. If you want
*anything* other than what RH or Novell or Canonical or Mandriva etc.
says you should want, then you have to hack the source code for your kernel.

Open source is great, and it is wonderful that you *can* hack the source
if you need to, but demanding that end users patch their source code
when all they want to do is load a module is really, really sad.

Please revert this patch. Its benefits are no where near its costs.

Crispin

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

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

[Jan Engelhardt]

On Oct 24 2007 13:18, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> On Oct 24 2007 19:11, Simon Arlott wrote:
>>   
>>> * (I've got a list of access rules which are scanned in order until one of 
>>> them matches, and an array of one bit for every port for per-port default 
>>> allow/deny - although the latter could be removed.
>>> http://svn.lp0.eu/simon/portac/trunk/)
>>>     
>> Besides the 'feature' of inhibiting port binding,
>> is not this task of blocking connections something for a firewall?
>>   
>So now you are criticizing his module. Arguing about the merits of
>security semantics. This is exactly why Linus wanted LSM, so we don't
>have to have these kinds of discussions, at least not on LKML :)

This was a question. I was perfectly aware that iptables alone
does not prohibit binding, and there are reasons to inhibit binding.

But sometimes, a coder does not know where to start - chances are,
that someone else wanting to do bind(2) inhibiting is doing it
with a syscall table change. Or coder did not notice that a firewall
is sufficient for the task to be achieved (which is not always the
case - hence the question).

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

[Casey Schaufler]

I have written Smack.
I need an LSM infrastructure.
I would prefer the old dynamic version.
I no trouble with the static version.

I think that a dynamic version is more useful, but I didn't want
what I'm doing to have it as a dependency, so I made sure that
it isn't. The debate about the inclusion of Smack can remain
blissfully separate from the dynamic/static LSM debate. This is
by design.

I have had a couple people suggest changes to Smack that would be
very elegently handled as stacked modules. These include "owned"
ports and additional uid restrictions. Since Smack is a MAC module
these other security features are not really appropriate to include
(if you want the Security Monolith there is SELinux) in it, but
certainly make sense to combine with it.

A stacker that does not require module participation could be quite
interesting. In the old day I felt that a security solution had to
include all aspects of control, but today I see the value provided
by independent mechanisms such as IPtables.



Casey Schaufler
casey@schaufler-ca.com

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

[Adrian Bunk]

On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
> On 24/10/07 13:55, Adrian Bunk 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?
> 
> No, because the interface for configuring it would be rejected... I have 
> a /proc file which I write a binary configuration file to. This works 
> fine for me but it would take a lot of work to write a proper interface 
> - which I'm still not sure how to do*.
>...

Generally, the goal is to get external modules included into the kernel.

You want to be able to have this functionality and you do not want to 
use SELinux for it.

But instead of working on getting your code into the kernel you are 
requesting that an API making it easier for you to maintain it 
externally comes back.

There are other points in this thread that might or might not warrant 
making LSM modular again, but even though it might sound harsh breaking 
external modules and thereby making people aware that their code should 
get into the kernel is IMHO a positive point.

> 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)

[Casey Schaufler]

--- Adrian Bunk <bunk@kernel.org> wrote:

> ...
> 
> There are other points in this thread that might or might not warrant 
> making LSM modular again, but even though it might sound harsh breaking 
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

Those proposing LSM modules over the past couple years have
been treated most harshly. I have personally taken the least
flak of anyone on my proposal, and at that there have been
times where I felt like pulling out the #5 clue stick and
taking a few swings. It's no wonder that people are afraid
to suggest a module. I didn't do it until I had combed through
the archives and prepared answers for the most common attacks.
I hope that Smack moving forward will defuse some of the bad
vibes that have clouded the LSM for so long. I don't blame
anyone who kept their module to themself given the hostility
which even successful products have encountered.

And don't give me the old "LKML is a tough crowd" feldercarb.
Security modules have been much worse. Innovation, even in
security, is a good thing and treating people harshly, even
"for their own good", is an impediment to innovation.


Casey Schaufler
casey@schaufler-ca.com

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

[Adrian Bunk]

On Wed, Oct 24, 2007 at 03:58:02PM -0700, Casey Schaufler wrote:
> 
> --- Adrian Bunk <bunk@kernel.org> wrote:
> 
> > ...
> > 
> > There are other points in this thread that might or might not warrant 
> > making LSM modular again, but even though it might sound harsh breaking 
> > external modules and thereby making people aware that their code should 
> > get into the kernel is IMHO a positive point.
> 
> Those proposing LSM modules over the past couple years have
> been treated most harshly. I have personally taken the least
> flak of anyone on my proposal, and at that there have been
> times where I felt like pulling out the #5 clue stick and
> taking a few swings. It's no wonder that people are afraid
> to suggest a module. I didn't do it until I had combed through
> the archives and prepared answers for the most common attacks.
> I hope that Smack moving forward will defuse some of the bad
> vibes that have clouded the LSM for so long. I don't blame
> anyone who kept their module to themself given the hostility
> which even successful products have encountered.
> 
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.

What I'm giving you is "Linus has decreed there can be LSMs other than 
SELinux."

Getting LSMs included should no longer be harder than for other 
parts of the kernel.

And don't get me wrong, I'm not saying my point should decide this 
discussion. It's simply the point that making it harder for external 
code also has advantages.

> Casey Schaufler

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)

[Linus Torvalds]

On Thu, 25 Oct 2007, Adrian Bunk wrote:
> 
> What I'm giving you is "Linus has decreed there can be LSMs other than 
> SELinux."
> 
> Getting LSMs included should no longer be harder than for other 
> parts of the kernel.

Well, despite my heart-felt feelings that we should support different 
people in trying out different things, one of the issues is also that I'm 
obviously not myself a security person. I can "decree" all I want, but in 
the end, I really want the people *involved* to merge security stuff. 

Right now Chris Wrigt is the documented maintainer for LSM, and quite 
frankly, I do not want to take it over. I really really really hope that
people that are interested in security can work this thing out, and my 
only requirement is that it doesn't end up being any kind of force-feeding 
of opinions and ideas, since clearly there is tons of room for 
disagreement in the area..

Do other people want to stand up and be "LSM maintainers" in the sense 
that they also end up being informed members who can also stand up for new 
modules and help merge them, rather than just push the existing one(s)? 
Chris? Casey? Crispin?

[ Ie there's the "core LSM hooks" on one side, but there's also the "what 
  modules make any sense at all to merge?" on the other, and I really 
  don't have the expertise to make any sensible judgements except for the 
  pure "process" judgement that we should not hardcode things to just one 
  module! ]

		Linus

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

[Chris Wright]

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> Do other people want to stand up and be "LSM maintainers" in the sense 
> that they also end up being informed members who can also stand up for new 
> modules and help merge them, rather than just push the existing one(s)? 
> Chris? Casey? Crispin?

Stephen and James, despite their clear bias towards SELinux, do try to
give good feedback.  But you are right, there's not enough active help
for people trying to make a contribution to get their code in shape.
Many of the modules that come along have been misguided conceptually,
but I think that e.g. apparmor, tomoyo, smack could use that kind
of constructive help to get into final mergable shape.  Personally,
I haven't spent nearly enough time reviewing those, my apologies to
those developers.  So, yes, help is welcome.

thanks,
-chris

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

[Arjan van de Ven]

On Wed, 24 Oct 2007 17:41:28 -0700
Chris Wright <chrisw@sous-sol.org> wrote:

> * Linus Torvalds (torvalds@linux-foundation.org) wrote:
> > Do other people want to stand up and be "LSM maintainers" in the
> > sense that they also end up being informed members who can also
> > stand up for new modules and help merge them, rather than just push
> > the existing one(s)? Chris? Casey? Crispin?
> 
> Stephen and James, despite their clear bias towards SELinux, do try to
> give good feedback.  But you are right, there's not enough active help
> for people trying to make a contribution to get their code in shape.
> Many of the modules that come along have been misguided conceptually,
> but I think that e.g. apparmor, tomoyo, smack could use that kind
> of constructive help to get into final mergable shape.  Personally,
> I haven't spent nearly enough time reviewing those, my apologies to
> those developers.  So, yes, help is welcome.
> 

I'll be happy to help out; I'd consider my self neutral in this space
not having worked with any of the LSM out there. I do think we need to
be somewhat critical to what we accept; we should at least be able to
filter out "pretend security" somehow. (this is not the same as saying
that you're bad if you only provide a limited security, in the
contrary, I strongly believe in simple pieces. What I mean is that we
should be critical to things that appear/claim to be strong but are
not).

Secondly, we should make sure that no new holes are added (the original
SMACK series suffered from this, Al Viro helped getting that reviewed
bigtime).

In addition we probably should strive to getting some sort of rough
"this is sort of where we draw the line" guideline set up, just to keep
things more objective.

(Oh and of course, if a security module is deeply involved in another
kernel subsystem, say networking or the VFS, very obviously we should
consult and listen to the respective maintainers of that subsystem; LSM
is not there to be a big hook to bypass the process of well maintained
subsystems)

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

[Toshiharu Harada]

On 10/25/2007 9:41 AM, Chris Wright wrote:
> * Linus Torvalds (torvalds@linux-foundation.org) wrote:
>> Do other people want to stand up and be "LSM maintainers" in the sense 
>> that they also end up being informed members who can also stand up for new 
>> modules and help merge them, rather than just push the existing one(s)? 
>> Chris? Casey? Crispin?
> 
> Stephen and James, despite their clear bias towards SELinux, do try to
> give good feedback.  But you are right, there's not enough active help
> for people trying to make a contribution to get their code in shape.
> Many of the modules that come along have been misguided conceptually,
> but I think that e.g. apparmor, tomoyo, smack could use that kind
> of constructive help to get into final mergable shape.  Personally,
> I haven't spent nearly enough time reviewing those, my apologies to
> those developers.  So, yes, help is welcome.

Yes, TOMOYO Linux is committed to help.
I mean, please count me in.

PS
Chris, I've been waiting for your comments for our code. :)

Regards,
Toshiharu Harada

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

[Casey Schaufler]

--- Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Thu, 25 Oct 2007, Adrian Bunk wrote:
> > 
> > What I'm giving you is "Linus has decreed there can be LSMs other than 
> > SELinux."
> > 
> > Getting LSMs included should no longer be harder than for other 
> > parts of the kernel.
> 
> Well, despite my heart-felt feelings that we should support different 
> people in trying out different things, one of the issues is also that I'm 
> obviously not myself a security person. I can "decree" all I want, but in 
> the end, I really want the people *involved* to merge security stuff. 
> 
> Right now Chris Wrigt is the documented maintainer for LSM, and quite 
> frankly, I do not want to take it over. I really really really hope that
> people that are interested in security can work this thing out, and my 
> only requirement is that it doesn't end up being any kind of force-feeding 
> of opinions and ideas, since clearly there is tons of room for 
> disagreement in the area..
> 
> Do other people want to stand up and be "LSM maintainers" in the sense 
> that they also end up being informed members who can also stand up for new 
> modules and help merge them, rather than just push the existing one(s)? 
> Chris? Casey? Crispin?

Count me in.

> [ Ie there's the "core LSM hooks" on one side, but there's also the "what 
>   modules make any sense at all to merge?" on the other, and I really 
>   don't have the expertise to make any sensible judgements except for the 
>   pure "process" judgement that we should not hardcode things to just one 
>   module! ]
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 


Casey Schaufler
casey@schaufler-ca.com

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

[Chris Wright]

* Casey Schaufler (casey@schaufler-ca.com) wrote:
> And don't give me the old "LKML is a tough crowd" feldercarb.
> Security modules have been much worse. Innovation, even in
> security, is a good thing and treating people harshly, even
> "for their own good", is an impediment to innovation.

I agree that innovation is critical to the success of Linux, and security
is not immune to that.  The trouble is that most of the security modules
that have come forward have had some real serious shortcomings.  I do
believe it is prudent to keep in-tree security sensitive code under
high scrutiny because we do not want to create security holes by adding
problematic security code.

thanks,
-chris

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

[Ray Lee]

On 10/24/07, Chris Wright <chrisw@sous-sol.org> wrote:
> * Casey Schaufler (casey@schaufler-ca.com) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for their own good", is an impediment to innovation.
>
> I agree that innovation is critical to the success of Linux, and security
> is not immune to that.  The trouble is that most of the security modules
> that have come forward have had some real serious shortcomings.

Key-based masterlocks are easily broken with freon, and their combo
locks are easily brute-forced in about ten minutes. Yet, I'll still
use them to lock up my bike and garage.

The idea that poor security is worse than no security is fallacious,
and not backed up by common experience.

> I do
> believe it is prudent to keep in-tree security sensitive code under
> high scrutiny because we do not want to create security holes by adding
> problematic security code.

If security code actively *adds* holes, then that's obviously a deal breaker.

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

[Peter Dolding]

I have different deal breakers.

If a LSM is something simple/commonly required it should be made like
posix file capability's provided to all to use.   Sorry to say I see
the file protection in apparmor as something everyone should be able
to use at will like posix file capability's.  All enforcement features
should be common.

I see a LSM as a director commander its reason for existence is to
read security configs and hand them permissions and respond to
problems.   Any enforcement should be default in kernel.

So LSM could be roll based, mac or any other model.  Current problem
enforcement and guiding are mixed up in one block.  So evolution is
not happening.

The enforcing bits of LSM's should be a simple no brainier addons to
the Linux kernel.  The problem is at moment they are mixed up with Mac
....  A security model to use has to be picked to suit job.   Role
Based can be Better than Mac and Mac can be better than Role based.
It all depends on what you are defending.

Thing common all need to protect suid, file access, network access...
The bits you need to defend don't change if or if not you are running
a LSM.  So why are these bits bottled up inside LSM forcing people to
choose the wrong security model for there task to get protection at
times.

There can never be one LSM to do every job.   But the big but all the
common bits to protect every job could be in kernel.  Only thing
missing is the director.

This is exactly the same problem Virtual Server solutions had when
then wanted to get into the kernel.   At least the Virtual Server
solutions were not as pig headed as some of the LSM guys about it.
Where its all in or not in at all.   Little bits into kernel is better
than nothing.

Really this will sound bad if I had my way I would kick all LSM's out
of the main kernel tree until they learn to work with each other to
share bits.  We don't need 10 copies of protect files from access.  Or
10 copies of limit what .so a application and interface with and so
on.

It worked with Virtual Servers to get them to sit down and start
talking.  What we really need working on is system wide security.  No
bothering a lot about the little box of LSM.

Yes I am not nice to LSM.   I see them as bitrot.  They are going to
cause containers problems in there current form as containers evolve.
They are not improving the base line security level.  Yes selinux
saying make me default to improve secuity says that in selinux there
are parts that should be chopped out and made default.  But since it
contains a security model it cannot be all made default because it
just will not fit everywhere.

Basically a LSM should make it simpler to run security tight.  The big
all mighty but it should not alter achievable security.  If its
altering achievable security main kernel is missing features and
someone needs to slice and dice that LSM.

Peter Dolding

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

[Alan Cox]

> The idea that poor security is worse than no security is fallacious,
> and not backed up by common experience.

There is a ton of evidence both in computing and outside of it which
shows that poor security can be very much worse than no security at all.
In particular stuff which makes users think they are secure but is
worthless is very dangerous indeed.

When you know that security is limited you act appropriately, when you
believe security is good but it is not you take inappropriate risks and
get badly burned.

Alan

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

[david]

On Thu, 25 Oct 2007, Alan Cox wrote:

>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.

there is also pleanty of evidence that you don't have to be perfect to be 
good enough.

in addition security is useually traded off for something else 
(useability, administrative effort, money, etc) and depending on what's 
being protected the cost that's appropriate is going to be different.

> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.

This is very true, but the solution isn't to try and eliminate everything 
other then perfect security, it's to properly document the limitations of 
various options and educate people about them.

David Lang

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

[Ray Lee]

On 10/24/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > The idea that poor security is worse than no security is fallacious,
> > and not backed up by common experience.
>
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.

(So, I take it that you *don't* lock your bike up, as poor security is
worse than none?)

While I believe you, I'd love to see references as it doesn't match my
day-to-day experience with Win/Mac end-users over the past ten years.

> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.

I have no trouble believing that.

> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.

'Inappropriate risks' nowadays is surfing the web and opening up mail
attachments that claim to be movies of dancing bears. I'd argue that
users have a reasonable expectation that these are things that should
'just work,' and be safe, much as normal humans have an expectation
that their car isn't going to explode when they turn the ignition.

Perfect is the enemy of good, or words to that effect, right? My point
is that requiring perfection out of a security framework is a bar
that's going to be awfully difficult to reach (and when it supposedly
has been achieved, as in SELinux, mere mortals find it too troublesome
to run with as it's far too difficult to configure). Security can and
should be done in layers, and what one may miss, another may catch.

Ray

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

[Alan Cox]

> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
> 
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)

On the contrary because I know it is not secure I would

a) Insure it
b) Not waste vast amounts of money on a useless expensive lock
c) Make sure the bike looked not worth stealing
d) Take the saddle with me

(or the software versions of that

a) Keep backups
b) Not waste vast amounts of money on bogus security software
c) Keep the system looking uninteresting
d) Encrypt the data)

> 'Inappropriate risks' nowadays is surfing the web and opening up mail
> attachments that claim to be movies of dancing bears. I'd argue that
> users have a reasonable expectation that these are things that should
> 'just work,' and be safe, much as normal humans have an expectation
> that their car isn't going to explode when they turn the ignition.

Yes and its very clear from the things said by politicians that if the
computer software people don't do this soon, the legislators will make
very sure they do by stripping away all the techniques used to hide from
liability for failure.

> Perfect is the enemy of good, or words to that effect, right? My point
> is that requiring perfection out of a security framework is a bar
> that's going to be awfully difficult to reach (and when it supposedly
> has been achieved, as in SELinux, mere mortals find it too troublesome
> to run with as it's far too difficult to configure). Security can and
> should be done in layers, and what one may miss, another may catch.

Absolutely - but those layers should do whatever they do *right* and
really do it, whether they are complex whole system controls like SELinux
or simple network security tools.

Alan

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

[david]

On Thu, 25 Oct 2007, Alan Cox wrote:

>>> There is a ton of evidence both in computing and outside of it which
>>> shows that poor security can be very much worse than no security at all.
>>
>> (So, I take it that you *don't* lock your bike up, as poor security is
>> worse than none?)
>
> On the contrary because I know it is not secure I would
>
> a) Insure it

and the unsurance company would have a clause in the policy that wouldn't 
cover you unless you used a lock, becouse they recognise that while it 
wouldn't stop everyone there is a large group of potential thieves that it 
would stop.

> b) Not waste vast amounts of money on a useless expensive lock

who said the lock was expensive? and while you are not willing to spend 
money on a lock you are willing to spend (much more) money on an insurance 
policy.

David Lang

> c) Make sure the bike looked not worth stealing
> d) Take the saddle with me
>
> (or the software versions of that
>
> a) Keep backups
> b) Not waste vast amounts of money on bogus security software
> c) Keep the system looking uninteresting
> d) Encrypt the data)
>
>> 'Inappropriate risks' nowadays is surfing the web and opening up mail
>> attachments that claim to be movies of dancing bears. I'd argue that
>> users have a reasonable expectation that these are things that should
>> 'just work,' and be safe, much as normal humans have an expectation
>> that their car isn't going to explode when they turn the ignition.
>
> Yes and its very clear from the things said by politicians that if the
> computer software people don't do this soon, the legislators will make
> very sure they do by stripping away all the techniques used to hide from
> liability for failure.
>
>> Perfect is the enemy of good, or words to that effect, right? My point
>> is that requiring perfection out of a security framework is a bar
>> that's going to be awfully difficult to reach (and when it supposedly
>> has been achieved, as in SELinux, mere mortals find it too troublesome
>> to run with as it's far too difficult to configure). Security can and
>> should be done in layers, and what one may miss, another may catch.
>
> Absolutely - but those layers should do whatever they do *right* and
> really do it, whether they are complex whole system controls like SELinux
> or simple network security tools.
>
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

[Peter Dolding]

Ok lets get to a good point.

Lets define a key bit.   What is a good software security lock?

My define is that its available to be used everywhere its needed and
when ever its need without flaw.

This is where most LSM fall in a heap.  Because you have to have the
LSM loaded to have its security features and cannot always be mixed
with other LSM it failes the when ever it is needed test.

On top of this most LSM features don't provide any form of direct
control to non admin users or applications to lower there access
rights.  So it also fails to be used everywhere its needed.

Since the LSM design itself is flawed in my eyes.   These flaws make
it hard for LSM to share tech advantages with each other.   LSM are
very much like putting a lock threw the front wheel of a bike.   So
the thief removes the front wheel and walks off with the rest of the
bike.  The critical data is in the user accounts.

The big thing with most LSM how do they handle security inside a
application on a thread by thread base.  They don't reason it gets too
compex without known the internals of the application.

We are talking security here and design of LSM's are not offering the
option max security.

Max security has to get down to a single thread inside a application
with all the security blocking features LSM's offer.  Reason a flaw in
that thread could be made completely harmless even that the other
threads in the application has complete system rights.

Idea of Max is to keep application flaws to as minor security flaw as
they could have been.   Ie Hopefully no risk because the flaw happened
in a section of code with no rights.

This is virtually imposable for any form of profiling creating
security to ever do(LSM profile based security).  What is needed is
application controlled security with profile based security as fail
back.  I know this means ripping your LSM parts apart and designing in
application controls.  Allowing features to be shared between LSM and
even to be there when the LSM that feature came from is not being
used.

First goal should not be to get a LSM static linked into kernel or
anything else bar getting the security system to a point that max
security is on the table if people want it.

I will say this again in my eyes LSM's should be thrown out of the
kernel completely because they are only offering fake max security.
Selinux and other LSM's on max is not even close to what should be
offered.

Basically Linux is a sitting duck for data thief third party  that
steal from the users home directory personal information.   And its
not like application developers are being given the tools to prevent
that.  Cost and loss does not start only when applications normal
profile of access is breached.   It starts way before that.

Peter Dolding

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

[Pavel Machek]

Hi!

> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > There is a ton of evidence both in computing and outside of it which
> > shows that poor security can be very much worse than no security at all.
> 
> (So, I take it that you *don't* lock your bike up, as poor security is
> worse than none?)

I do lock my bike with combination lock I found somewhere and cracked
in five minutes... sometimes.

But do you suggest that I use paper tape to 'lock' my bike to
streetlight? You just said that poor security is better than none,
right?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Hua Zhong]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; linux-security-module@vger.kernel.org;
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
> 
> Hi!
> 
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
> 
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
> 
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
> 
> 							Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Hua Zhong]

I think you may be misinterpreting the word "poor" here.

Many people in this thread consider a security solution "poor" because it's
not "complete" or "perfect": it may work against attack ABC but not attack
XYZ. The defendants say that XYZ isn't possible in the environment that it's
supposed to be used, or XYZ may be too expensive to be worth implementing,
or they just are rare enough to be ignored. Heck, all security solutions
could be broke given physical access.

Implementing a security solution has a cost. Bypassing it also has a cost.
Sometimes it's economy, not technique, decides whether a particular security
solution is a good one.

Locks are a good example for this. It has a low cost/effect ratio, and very
easy to use. Is it 100% safe? Definitely not. People lock their bikes to a
tree when they enter a supermarket because it's reasonably safe. But leaving
their bikes like that over a few nights on a downtown street? Probably not a
good idea. Don't assume all people are idiots who do not know that (ok, some
people are, so the lock's manual states "it can be bypassed by a skilled
thief").

But what tapes are good for? I don't know what kind of value it adds to the
discussion.

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Saturday, October 27, 2007 11:29 AM
> To: Ray Lee
> Cc: Alan Cox; Chris Wright; Casey Schaufler; Adrian Bunk; Simon Arlott;
> linux-kernel@vger.kernel.org; linux-security-module@vger.kernel.org;
> Jan Engelhardt; Linus Torvalds; Andreas Gruenbacher; Thomas Fricaccia;
> Jeremy Fitzhardinge; James Morris; Crispin Cowan; Giacomo Catenazzi
> Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
> static interface)
> 
> Hi!
> 
> > > > The idea that poor security is worse than no security is
> fallacious,
> > > > and not backed up by common experience.
> > >
> > > There is a ton of evidence both in computing and outside of it
> which
> > > shows that poor security can be very much worse than no security at
> all.
> >
> > (So, I take it that you *don't* lock your bike up, as poor security
> is
> > worse than none?)
> 
> I do lock my bike with combination lock I found somewhere and cracked
> in five minutes... sometimes.
> 
> But do you suggest that I use paper tape to 'lock' my bike to
> streetlight? You just said that poor security is better than none,
> right?
> 
> 							Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Crispin Cowan]

Alan Cox wrote:
>> The idea that poor security is worse than no security is fallacious,
>> and not backed up by common experience.
>>     
> There is a ton of evidence both in computing and outside of it which
> shows that poor security can be very much worse than no security at all.
> In particular stuff which makes users think they are secure but is
> worthless is very dangerous indeed.
>
> When you know that security is limited you act appropriately, when you
> believe security is good but it is not you take inappropriate risks and
> get badly burned.
>   
The "bad security is worse than no security" idea comes exactly from
what Alan says above: it happens when the security is not as good as you
think it is, and so you don't take adequate precautions.

Using the ongoing bicycle lock example, the discovery a few years ago
that a certain model of Kryptonite bike lock could be picked with a
simple pen made the security on this otherwise very sturdy lock become
abruptly very weak http://www.wired.com/culture/lifestyle/news/2004/09/64987

Conversely, the case can also be made that "weak security is better than
no security". It is better to secure your bike with a $10 lock than no
lock. If someone insists on only "high" security bike locks that cost
$1000 and weigh 30 lbs, then most people will choose to not lock their
bikes, or skip biking all together.

IMHO, much of the criticism leveled at proposed LSMs has been of the
latter kind, or worse. That the security of the proposed LSM does not
meet some particular use case does not make it "bad", it makes it not
for that use case.

To reject an LSM for providing "bad" security, IMHO you should have to
show how it is possible to subvert the self-stated goals of that LSM.
Complaints that the LSM fails to meet some goal outside of its stated
purpose is irrelevant. Conjecture that it probably can be violated
because of $contrivance is just so much FUD.

Exception: it is valid to say that the self-stated goal is too narrow to
be useful. But IMHO that bar of "too narrow" should be very, very low.
Defenses against specific modes of attack would be a fine thing to build
up in the library of LSMs, especially if we got a decent stacking module
so that they could be composed.

Crispin

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

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

[Alan Cox]

> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

That seems to be an appropriate test.

> Exception: it is valid to say that the self-stated goal is too narrow to
> be useful. But IMHO that bar of "too narrow" should be very, very low.
> Defenses against specific modes of attack would be a fine thing to build
> up in the library of LSMs, especially if we got a decent stacking module
> so that they could be composed.

Once you have stacking then it actually at times will make sense to have
security modules that do one very precise thing and do it well.

Alan

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

[serge]

(finally starting to make headway through this thread over a month late)

Quoting Alan Cox (alan@lxorguk.ukuu.org.uk):
> > To reject an LSM for providing "bad" security, IMHO you should have to
> > show how it is possible to subvert the self-stated goals of that LSM.
> > Complaints that the LSM fails to meet some goal outside of its stated
> > purpose is irrelevant. Conjecture that it probably can be violated
> > because of $contrivance is just so much FUD.
> 
> That seems to be an appropriate test.
> 
> > Exception: it is valid to say that the self-stated goal is too narrow to
> > be useful. But IMHO that bar of "too narrow" should be very, very low.
> > Defenses against specific modes of attack would be a fine thing to build
> > up in the library of LSMs, especially if we got a decent stacking module
> > so that they could be composed.
> 
> Once you have stacking then it actually at times will make sense to have
> security modules that do one very precise thing and do it well.

Hey - I thought it was the other way around?  :)

-serge

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

[Peter Dolding]

On 10/29/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

LSM is providing bad security on two fronts.

Number 1 LSM are speeding effort to create features.  Apparmor and
Selinux both provide file access filtering from applications.  Yet
they double up the code to do it.   So they cannot be used with each
other without doubling up hooks.  Then other LSM are creating there
own sections of code to do the same thing.   Simple rule more code
more risk of bugs since it will be less audited.  Duplication defense
features is really bad for security.  Some how code sharing has to be
got into LSM construction.

Number 2 The critical bit LSM stop at the edges of applications.   Now
without overlapping my hooks with existing LSMs I cannot create
application level protections.  Overlapping hooks will cause speed
loss.

LSM is set to protect the application. But inside the application
there will be sections that need the access rights and others that
don't.  Now a exploit in any section of the application under LSM gets
the LSM assigned rights.   With application level this can be done a
few ways extension to elf that is create by the complier and api calls
lowering access functions of current thread or for a starting thread.
If you exploit a section of the code without access to disk network
access and so on and without the right to call any function that does
that.   What have you exploited.   Minor data damage compared to
complete data that the application have access to being stolen as what
is the case with LSM at moment.  Basically LSM prevent taking control
of the complete system but don't help to stop peoples private data
from being stolen.  Both are bad to happen to a person.

LSM design is there to help security development not get in its way or
to cause bitrot.  Currently LSM design is causing major risk bitrot in
duplicated code.

Reading and processing configuration files should be independent to
the protection methods.   Hopefully designed to be able to run user
mode to test if the new profile for a application is safe to add
before adding it to the OS.   Typo prevention on both sides.  Current
method of just sticking everything into one huge blob is preventing
code sharing and risking more security holes.

The current LSM design is bad on so many levels.  I am surprised that
it takes a Non PHD System Admin to see it.  Some how I think its a
empire thing.   If everything was just simple blocks a person could
write a new LSM in hours with pretty good security.  Compared to
todays long time trying effort.  Leads of Apparmor selinux and so on
not being prepared to give up there little empire for the greater
good.

I personally hate stacking as a idea.  I personally prefer two layers
only.  Config reading and  enforcement.   Of course that does not stop
applications being assigned to different config reading systems.
Depth the two layers should stay fixed even if you have many different
models in use.

All LSM seam to want to force System Admins to pick there LSM over
another.   Instead of being able to pick LSM for task at hand.   Same
with poor security being better than no security its true.  Its
nothing strange to find selinux based systems with there security
disabled because the Admin cannot configure it.   But the reverse is
also true that when you have skilled Admins stuck with a system like
Apparmor cannot harden the system as far as they could with selinux.
Both ways its causing security holes poor security when you should
have good security is bad too.  Part of the problem LSM maintainers
are not at the front lines is all I can guess.  Because they don't
seam to know what is really needed.

Peter Dolding

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

[Arjan van de Ven]

On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan <crispin@crispincowan.com> wrote:

> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.

exactly; this is why I've been pushing recently for each new LSM to at
least document and make explicit what it tries to protect / protect
against (threat model and defense model in traditional security terms).
Without such an explicit description it's both impossible to
"neutrally" review a proposed LSM towards its goals, and it ends up as
a result with people making assumptions and attacking the model because
there's no separation between code and model.

 
> Exception: it is valid to say that the self-stated goal is too narrow
> to be useful. But IMHO that bar of "too narrow" should be very, very
> low. Defenses against specific modes of attack would be a fine thing
> to build up in the library of LSMs, especially if we got a decent
> stacking module so that they could be composed.

again I agree pretty much; I do want to reserve some minimum "common
sense" bar because people may (and probably will) do silly things withs
LSMs that are really not the right thing to do objectively.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Bernd Petrovitsch]

On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
[....]
> Key-based masterlocks are easily broken with freon, and their combo
> locks are easily brute-forced in about ten minutes. Yet, I'll still
> use them to lock up my bike and garage.

The question is what the security threat is and the value of the secured
items.

> The idea that poor security is worse than no security is fallacious,
> and not backed up by common experience.

The common experience is, that common people just *feel* safer (just
because they have poor security).
With no security, they know that there is no security. With poor
security, they do not know (or can deny) that they have next to no real
security.
The prime example here is the usual (so-called) "personal firewall" on
Windows where people work normally as "administrator".

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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

[Ray Lee]

On 10/25/07, Bernd Petrovitsch <bernd@firmix.at> wrote:
> On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> [....]
> > Key-based masterlocks are easily broken with freon, and their combo
> > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > use them to lock up my bike and garage.
>
> The question is what the security threat is and the value of the secured
> items.
>
> > The idea that poor security is worse than no security is fallacious,
> > and not backed up by common experience.
>
> The common experience is, that common people just *feel* safer (just
> because they have poor security).

Do you lock your bike up when you leave it lying around? My point is
that real security comes in layers, not one perfect solution that will
always work everywhere for everyone. The latter is a pipe-dream.

> With no security, they know that there is no security. With poor
> security, they do not know (or can deny) that they have next to no real
> security.

The fallacy here is to believe that just because they have no
security, that it will *in*any*way* change their behavior. I deal with
real users daily, and *they*don't*care*. Further, there's no level of
education that we can instill into the community to make them aware of
the issues and change their habits accordingly, because real users
don't have the background to understand those lessons.

While you can teach them that running an executable from someone they
haven't heard of is obviously bad, they don't know why downloading an
image is potentially dangerous, "it's an image, right?" "Well, there's
these things called buffer overflows..." <eyes glaze over>

Security is not an all or nothing game, it's layers. And we have to
make sure that the layers are usable without taking a course from the
NSA. I'd love to see a poll of the kernel development community to
find out how many use SELinux on their machines, for example.

> The prime example here is the usual (so-called) "personal firewall" on
> Windows where people work normally as "administrator".

So your argument is that if there weren't a personal firewall on
Windows, that a significant number of people would then not run as
Administrator? I beg to differ.

Ray

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

[Arjan van de Ven]

On Thu, 25 Oct 2007 09:04:57 -0700
"Ray Lee" <ray-lk@madrabbit.org> wrote:


> Security is not an all or nothing game, it's layers. And we have to
> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.

I absolutely agree it's a layer game.
HOWEVER, even in a layer game we need to have each layer to be
reasonably solid and not just fake security ("snakeoil").

So while I think it is entirely fair to judge a piece of software
against what it intends/claims to do, because other pieces in the layer
game will depend on it to function reasonably well. 

So most of the LSM fist-fights have been about disagreement of the
intent; and some about code not living up to its own intend, all mixed
up. Arguing about the intent is less productive imo (as long as it's at
least somewhat reasonable, intend like "I want to add rootkits" doesn't
count obviously), paying attention to check if the code lives up to its
stated intent/purpose on the other hand is immensely useful and needed;
for a given implementation it may mean reducing the scope of the intent
if the implementation just doesn't go as wide as originally thought, or
fixing some issues in the implementation to live up to the intent.

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

[Bernd Petrovitsch]

On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote:
> On 10/25/07, Bernd Petrovitsch <bernd@firmix.at> wrote:
> > On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote:
> > [....]
> > > Key-based masterlocks are easily broken with freon, and their combo
> > > locks are easily brute-forced in about ten minutes. Yet, I'll still
> > > use them to lock up my bike and garage.
> >
> > The question is what the security threat is and the value of the secured
> > items.
> >
> > > The idea that poor security is worse than no security is fallacious,
> > > and not backed up by common experience.
> >
> > The common experience is, that common people just *feel* safer (just
> > because they have poor security).
> 
> Do you lock your bike up when you leave it lying around? My point is
> that real security comes in layers, not one perfect solution that will
> always work everywhere for everyone. The latter is a pipe-dream.

Of course not. "Security" as such is more than less "only" risk
management (or part of it - depending of the viewpoint).

> > With no security, they know that there is no security. With poor
> > security, they do not know (or can deny) that they have next to no real
> > security.
> 
> The fallacy here is to believe that just because they have no
> security, that it will *in*any*way* change their behavior. I deal with
> real users daily, and *they*don't*care*. Further, there's no level of

If people don't care, they are pretty lost anyway.
That's actually the reason for all that security stuff that no one wants
but which stands in the way of all people just because of the "don't
care" faction (which by far the majority of all in any given area).
But there is that (also not too small) "I installed $PERSONAL_FIREWALL
and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in
$LOW_QUALITY_PC_MAG said so" faction.

> education that we can instill into the community to make them aware of
> the issues and change their habits accordingly, because real users
> don't have the background to understand those lessons.
> 
> While you can teach them that running an executable from someone they
> haven't heard of is obviously bad, they don't know why downloading an
> image is potentially dangerous, "it's an image, right?" "Well, there's
> these things called buffer overflows..." <eyes glaze over>
> 
> Security is not an all or nothing game, it's layers. And we have to

And every layer/subsystem/area must be checked and seen independently of
others (or the dependency must be that strong that no one can work
around).
And every security layer will and should have it's purpose and targets.

> make sure that the layers are usable without taking a course from the
> NSA. I'd love to see a poll of the kernel development community to
> find out how many use SELinux on their machines, for example.

"selinux=0" on the kernel commandline is normal - no unknown people have
logins and so there was no reason to learn it. And against should it
protect in the first place if only trusted people are there?

> > The prime example here is the usual (so-called) "personal firewall" on
> > Windows where people work normally as "administrator".
> 
> So your argument is that if there weren't a personal firewall on
> Windows, that a significant number of people would then not run as
> Administrator? I beg to differ.

No, how do you come to that conclusion?

People login as "Administrator" because they did it since DOS3.0.
People buy and install $PERSONAL_FIREWALL because some cheap PC tech
magazine had advertisements for them.
Next generation (or this generation?) viruses/malware will either
reconfigure $PERSONAL_FIREWALL silently (and if course only
temporarily).
And the vendor of $PERSONAL_FIREWALL writes into the manual (which no
one reads) or the EULA (which no one reads because it isn't relevant in
the first place) or some README (which no one finds) that one must not
login as "Administrator". But that just to keep the vict^Wbuyers to not
sue them. And working on Win* without being "Administrator" is a real
PITA - so the average user won't do it for long.

So apart from the personal feelings of that user I can't find any sign
of security.

BTW from a commercial viewpoint, the (so-called) "personal firewalls"
were probably one of the best ideas (and another major example that
technical expertise has nothing to do with sales success).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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

[Casey Schaufler]

--- Chris Wright <chrisw@sous-sol.org> wrote:

> * Casey Schaufler (casey@schaufler-ca.com) wrote:
> > And don't give me the old "LKML is a tough crowd" feldercarb.
> > Security modules have been much worse. Innovation, even in
> > security, is a good thing and treating people harshly, even
> > "for their own good", is an impediment to innovation.
> 
> I agree that innovation is critical to the success of Linux, and security
> is not immune to that.  The trouble is that most of the security modules
> that have come forward have had some real serious shortcomings.  I do
> believe it is prudent to keep in-tree security sensitive code under
> high scrutiny because we do not want to create security holes by adding
> problematic security code.

I agree that security code does need to provide security. What we
need to get away from is the automatic attacks that are based on 20th
century computer system assumptions. Things like "name based access
control is rediculous", and "a module can't be any good if it doesn't
deal with all objects", or "the granularity isn't fine enough". Look
at TOMOYO. It's chuck full of good ideas. Why spend so much energy
badgering them about not dealing with sockets? How about helping the
AppArmor crew come up with acceptable implementations rather than
whinging about the evils of hard links? And maybe, just maybe, we can
get away from the inevitable claim that you could do that with a few
minutes work in SELinux policy, but only if you're a security
professional of course.

Sure, some LSM proposals will be lousy, and some really will be
better done as an SELinux policy module. Some will even have merit
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and isn't secure. Security is subjective. It's how you feel
about it.



Casey Schaufler
casey@schaufler-ca.com

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

[Pavel Machek]

Hi!

> but require unreasonable interface changes. As people who care
> about security (y'all who are only from the LKML are excused) it
> is our obligation to look beyond the preconceived notions of what
> is and isn't secure. Security is subjective. It's how you feel
> about it.

<sarcasm>Hmm. So lets add automagic security module. It magically fixes
security holes, and you can feel good about it.</sarcasm>


							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux Security *Module* Framework

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

Am 27.10.2007 20:22 schrieb Pavel Machek:
> Hi!
> 
>> but require unreasonable interface changes. As people who care
>> about security (y'all who are only from the LKML are excused) it
>> is our obligation to look beyond the preconceived notions of what
>> is and isn't secure. Security is subjective. It's how you feel
>> about it.
> 
> <sarcasm>Hmm. So lets add automagic security module. It magically fixes
> security holes, and you can feel good about it.</sarcasm>

Send patch.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: Linux Security *Module* Framework

[Jan Engelhardt]

On Oct 28 2007 20:42, Tilman Schmidt wrote:
>Am 27.10.2007 20:22 schrieb Pavel Machek:
>> Hi!
>> 
>>> but require unreasonable interface changes. As people who care
>>> about security (y'all who are only from the LKML are excused) it
>>> is our obligation to look beyond the preconceived notions of what
>>> is and isn't secure. Security is subjective. It's how you feel
>>> about it.
>> 
>> <sarcasm>Hmm. So lets add automagic security module. It magically fixes
>> security holes, and you can feel good about it.</sarcasm>
>
>Send patch.

Perfect security from threats that normally deliver via internet!
(And it is even one of these that benefit from being modular!)

#include <linux/kmod.h>
#include <linux/module.h>
#include <linux/netdevice.h>
#include <net/net_namespace.h>

static void cl(const char *name, const char *state)
{
	const char *args[] = {"ip", "link", "set", name, state, NULL};
	call_usermodehelper("/sbin/ip", (char **)args, NULL, UMH_NO_WAIT);
}  

int __init automagic_security_init(void)
{
	const struct net_device *dev;

	for_each_netdev(&init_net, dev)
		cl(dev->name, "down");

	return 0;
}

void __exit automagic_security_exit(void)
{
	const struct net_device *dev;   
 
	for_each_netdev(&init_net, dev)
		cl(dev->name, "up");

        return;
}

module_init(automagic_security_init);
module_exit(automagic_security_exit);

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

[Toshiharu Harada]

On 10/25/2007 10:42 AM, Casey Schaufler wrote:
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.

Casey,

Thank you introducing TOMOYO Linux. I really like your idea of
simplified MAC (and you work so hard!). I also find advantages
of AppArmor for distributing policies with less hustle. Finally
and most importantly, I respect SELinux as the first in-tree,
flexible and reliable security frame work and respect developers
involved.

As a project manager of TOMOYO Linux, I would like to
push it, of course. But I noticed, if each of LSM module
developer begin pushing their own code, that's not for the
sake of Linux and we may end up with chaos.

Instead of pushing TOMOYO Linux, I started developing
comparison chart of security-enhance Linux implementations.
The current version can be found in

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

I would like to receive feedbacks from Stephen, Crispin
(you already have a comparison, though :),
Casey and any people interested in. If possible,
I would like to include opinions from BSD people.

I would like LSM to be the result of common requirements.
"Common" means good in general, but not always for security
perspective. IMHO, I think it is possible for us to get to the
conclusion not to have a framework.

Cheers (and with love to Linux),
Toshiharu Harada

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

[Jan Engelhardt]

On Oct 30 2007 12:23, Toshiharu Harada wrote:
>
> Instead of pushing TOMOYO Linux, I started developing
> comparison chart of security-enhance Linux implementations.
> The current version can be found in
>
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

Smack Security Model: autolabel, as far as I can tell.
Smack Policy Generation: user - hand - and an editor
Apparmor tutorial (beats any FAQ at first):
	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi

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

[Crispin Cowan]

Jan Engelhardt wrote:
> Apparmor tutorial (beats any FAQ at first):
> 	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>   
Thanks for the high praise. Unfortunately that FTP site seems to not be
working. Some alternatives:

    * My personal copy of the above video
      http://crispincowan.com/~crispin/FOSDEM2006-apparmor.avi
    * Similar talk at linux.conf.au 2007
      http://youtube.com/watch?v=EgrfmSm0NWs
    * Similar talk at Defcon 2007
      http://video.google.com/videoplay?docid=-1731833784646588861&hl=en

Crispin

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

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

[Jan Engelhardt]

On Oct 30 2007 01:50, Crispin Cowan wrote:
>Jan Engelhardt wrote:
>> Apparmor tutorial (beats any FAQ at first):
>> 	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
>>   
>Thanks for the high praise. Unfortunately that FTP site seems to not be
>working. Some alternatives:
[...]

Actually, if the selinux team would do the same [introductionary video],
I'd guess the hardness level commonly associated with selinux could be
relieved a bit.

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

[Toshiharu Harada]

On 10/30/2007 5:40 PM, Jan Engelhardt wrote:
> On Oct 30 2007 12:23, Toshiharu Harada wrote:
>> Instead of pushing TOMOYO Linux, I started developing
>> comparison chart of security-enhance Linux implementations.
>> The current version can be found in
>>
>> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
> 
> Smack Security Model: autolabel, as far as I can tell.
I noticed the smell of danger in the naming of "Security Model".
Please allow me some time.

> Smack Policy Generation: user - hand - and an editor
> Apparmor tutorial (beats any FAQ at first):
> 	ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi
Updated above two items. Thank you. :)

I'm not an optimist to believe we can reach the perfect
comparison. The purpose is to feed information, not to judge.
This might sound ironically, but I don't really think
we can *compare* them because they have different
theories/purposes/backgrounds. Some kind of forgiveness and
fuzziness are required.

As I don't want to steal everybody's bandwidth,
simple updates will be done silently. Your suggestions and
information will be greatly appreciated despite of
visible evidence.

Thank you.
Toshiharu Harada

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

[Simon Arlott]

On Wed, October 24, 2007 23:31, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
>> On 24/10/07 13:55, Adrian Bunk 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?
>>
>> No, because the interface for configuring it would be rejected... I have
>> a /proc file which I write a binary configuration file to. This works
>> fine for me but it would take a lot of work to write a proper interface
>> - which I'm still not sure how to do*.
>>...
>
> Generally, the goal is to get external modules included into the kernel.
>
> You want to be able to have this functionality and you do not want to
> use SELinux for it.

SELinux couldn't do it when I wrote my own module, it may do now but I
haven't checked - that's also far too much extra configuration overhead
to do something relatively simple.

> But instead of working on getting your code into the kernel you are
> requesting that an API making it easier for you to maintain it
> externally comes back.

It's also much harder to maintain it internally too since it can no
longer be compiled as a module. If it were possible to have to make LSM
usable as a module but without secondary support, that would make
development easier - although secondary support is so trivial I doubt
it makes a difference to the possibility of allowing it to be compiled
as a module again.

> There are other points in this thread that might or might not warrant
> making LSM modular again, but even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.

You're only going to be forcing me to spend *my* time developing it into
something that could be accepted into the kernel when it works fine for
me already. Then I'd have to convince the LSM maintainer(s) that it
should be merged - this isn't like an external hardware driver where
there's no existing support in the kernel.


>> Simon Arlott
>
> cu
> Adrian


-- 
Simon Arlott

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Am 25.10.2007 00:31 schrieb Adrian Bunk:
> Generally, the goal is to get external modules included into the kernel.
> [...] even though it might sound harsh breaking
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

This argument seems to start from the assumption that any externally
maintained kernel code *can* get into the kernel, which doesn't stand
up to  reality. Once you admit that there is code which, for very good
reasons, won't ever be accepted into the mainline kernel tree, what you
are saying amounts to: "Code that isn't fit to be included in the
mainline kernel isn't fit to exist at all."

I'm not sure I can agree with that.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

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

[Greg KH]

On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> > Generally, the goal is to get external modules included into the kernel.
> > [...] even though it might sound harsh breaking
> > external modules and thereby making people aware that their code should 
> > get into the kernel is IMHO a positive point.
> 
> This argument seems to start from the assumption that any externally
> maintained kernel code *can* get into the kernel, which doesn't stand
> up to  reality. Once you admit that there is code which, for very good
> reasons, won't ever be accepted into the mainline kernel tree, what you
> are saying amounts to: "Code that isn't fit to be included in the
> mainline kernel isn't fit to exist at all."

What kind of code is not accepted into the mainline kernel tree for good
reasons?  What are these reasons?  What specific code are you talking
about?

I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things.  If you know of any that are not on the list at:
	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.

thanks,

greg k-h

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

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things.  If you know of any that are not on the list at:
>	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.

Do I have to at least try to submit it to LKML first before it is
even considered for the OOT wiki page? :-)

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

[Greg KH]

On Fri, Oct 26, 2007 at 09:09:05AM +0200, Jan Engelhardt wrote:
> 
> On Oct 25 2007 19:56, Greg KH wrote:
> >
> >I'm trying to compile a list of all known external modules and drivers
> >and work to get them included in the main kernel tree to help prevent
> >these kinds of things.  If you know of any that are not on the list at:
> >	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> >please feel free to add them, or email me with the needed information
> >and I will add them to the list.
> 
> Do I have to at least try to submit it to LKML first before it is
> even considered for the OOT wiki page? :-)

No, you can go hide on your own, that's what the majority of projects on
that page have done :)

But of course, it would be good for you to at least submit it and get
feedback.  Or, if you don't want to do it, the linuxdriverproject
developers would be glad to help you out...

thanks,

greg k-h

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]

On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>> Am 25.10.2007 00:31 schrieb Adrian Bunk:
>> > Generally, the goal is to get external modules included into the kernel.
>> > [...] even though it might sound harsh breaking
>> > external modules and thereby making people aware that their code should 
>> > get into the kernel is IMHO a positive point.
>> 
>> This argument seems to start from the assumption that any externally
>> maintained kernel code *can* get into the kernel, which doesn't stand
>> up to  reality. Once you admit that there is code which, for very good
>> reasons, won't ever be accepted into the mainline kernel tree, what you
>> are saying amounts to: "Code that isn't fit to be included in the
>> mainline kernel isn't fit to exist at all."
> 
> What kind of code is not accepted into the mainline kernel tree for good
> reasons?

- proprietary code
- unmaintained code
- code conflicting with existing kernel structure or policy
- code in which the concerned subsystem maintainers see no benefit
- code which its author is unable and/or unwilling to convert to
  kernel coding standards
- code whose author is unable and/or unwilling to defend it on LKML

> What are these reasons?

The details vary, but the fundamental reason is always the same: to
maintain a sufficient level of code quality in the kernel. Point in
case, the recent discussion whether drivers not supporting
suspend/resume should be refused to merge.

> What specific code are you talking about?

Some examples, in no particular order: Reiser4, AppArmor, VMware,
the staircase deadline scheduler, the first version of ser_gigaset,
the Matrox HAL module, SuSE's "taint extension". Yes, some of these
are in the kernel now, or have been superseded by other code that
is, but that doesn't invalidate my concern.

> I'm trying to compile a list of all known external modules and drivers
> and work to get them included in the main kernel tree to help prevent
> these kinds of things.  If you know of any that are not on the list at:
> 	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> please feel free to add them, or email me with the needed information
> and I will add them to the list.

That's certainly helpful, but I still think there will always be
a number of external modules that cannot be merged right now or at
all, and deliberately making life difficult for out-of-tree code
maintainers in order to coerce them into submitting their code for
inclusion in the kernel will not work, it'll only create bad
feelings.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

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

[Greg KH]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > I'm trying to compile a list of all known external modules and drivers
> > and work to get them included in the main kernel tree to help prevent
> > these kinds of things.  If you know of any that are not on the list at:
> > 	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> > please feel free to add them, or email me with the needed information
> > and I will add them to the list.
> 
> That's certainly helpful, but I still think there will always be
> a number of external modules that cannot be merged right now or at
> all, and deliberately making life difficult for out-of-tree code
> maintainers in order to coerce them into submitting their code for
> inclusion in the kernel will not work, it'll only create bad
> feelings.

Do you have examples of proof of this?  Read
Documentation/stable_api_nonsense.txt for how we already make
out-of-tree code developer's lives hell :)

thanks,

greg k-h

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

[Simon Arlott]

On 26/10/07 16:58, Greg KH wrote:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>> > I'm trying to compile a list of all known external modules and drivers
>> > and work to get them included in the main kernel tree to help prevent
>> > these kinds of things.  If you know of any that are not on the list at:
>> > 	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> > please feel free to add them, or email me with the needed information
>> > and I will add them to the list.
>> 
>> That's certainly helpful, but I still think there will always be
>> a number of external modules that cannot be merged right now or at
>> all, and deliberately making life difficult for out-of-tree code
>> maintainers in order to coerce them into submitting their code for
>> inclusion in the kernel will not work, it'll only create bad
>> feelings.
> 
> Do you have examples of proof of this?  Read
> Documentation/stable_api_nonsense.txt for how we already make
> out-of-tree code developer's lives hell :)

The change makes it much harder to develop in tree too. Also, this really 
needs to be reverted and put in the feature removal schedule... unless 
you intend to deliberately make all out of tree LSMs unusable with no 
warning and no time to have them added to the kernel? We're already at 
2.6.24-rc1.

-- 
Simon Arlott

eradicating out of tree modules (was: Linux Security *Module* Framework)

[Tilman Schmidt]

Greg KH schrieb:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> [...] I still think there will always be
>> a number of external modules that cannot be merged right now or at
>> all, and deliberately making life difficult for out-of-tree code
>> maintainers in order to coerce them into submitting their code for
>> inclusion in the kernel will not work, it'll only create bad
>> feelings.
> 
> Do you have examples of proof of this?

No proof in the legal, mathematical or scientific sense of the
term, but examples:

- at least one talented kernel developer giving up his work,
until then maintained out of tree, after submitting it for
inclusion in the kernel and taking the ensuing fla^Wdiscussion
on LKML (nothing extraordinary, just the usual lack of
courtesy and respect) too much to heart

- the furious flames on LKML each time someone dares posting
helpful information about getting non-GPL software working
again with the newest kernel version, which will certainly
never achieve inclusion of that software in the kernel but
definitely create bad feelings on both sides (righteous
indignation *is* a bad feeling in my book)

>  Read Documentation/stable_api_nonsense.txt for how we already make
> out-of-tree code developer's lives hell :)

Oh yes, that one. A key piece of evidence. Yes, I've read it,
though I sometimes wish I hadn't. Its very title supports my
observation on the creation of bad feelings, and the actual
text doesn't contradict it. (no ":)")

T.

Re: eradicating out of tree modules (was: Linux Security *Module* Framework)

[Adrian Bunk]

On Sat, Oct 27, 2007 at 04:07:41PM +0200, Tilman Schmidt wrote:
> Greg KH schrieb:
> > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> >> [...] I still think there will always be
> >> a number of external modules that cannot be merged right now or at
> >> all, and deliberately making life difficult for out-of-tree code
> >> maintainers in order to coerce them into submitting their code for
> >> inclusion in the kernel will not work, it'll only create bad
> >> feelings.
> > 
> > Do you have examples of proof of this?
> 
> No proof in the legal, mathematical or scientific sense of the
> term, but examples:
> 
> - at least one talented kernel developer giving up his work,
> until then maintained out of tree, after submitting it for
> inclusion in the kernel and taking the ensuing fla^Wdiscussion
> on LKML (nothing extraordinary, just the usual lack of
> courtesy and respect) too much to heart
>...

There's one important point to note:

In a project of the size of the Linux kernel (at about 2000 distinct 
people contributing code within one year) you will always lose 
developers:

If you require too much from code for getting it included you lose some 
of the people who develop code.

If you accept code of dubious quality you lose some of the people who 
care about the quality of the kernel.

And if you add a stable API for modules with not GPL compatible licences 
at least one untalented kernel developer (me) might give up his work.

If your goal is to please all developers you have a goal you can't 
achieve.

The only reasonable way is to accept that whatever you do you'll lose 
some people and go in the direction you consider the right one.

And the power of open source is that when an open source project gets 
into a direction many people dislike they can simply fork it. Consider 
e.g. XFree86->X.Org or NetBSD->OpenBSD. And that's nothing bad - either 
the forks develop in different directions creating different useful 
software or there's an evolutionary contest for the best software.

> T.

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)

[Adrian Bunk]

On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> >> > Generally, the goal is to get external modules included into the kernel.
> >> > [...] even though it might sound harsh breaking
> >> > external modules and thereby making people aware that their code should 
> >> > get into the kernel is IMHO a positive point.
> >> 
> >> This argument seems to start from the assumption that any externally
> >> maintained kernel code *can* get into the kernel, which doesn't stand
> >> up to  reality. Once you admit that there is code which, for very good
> >> reasons, won't ever be accepted into the mainline kernel tree, what you
> >> are saying amounts to: "Code that isn't fit to be included in the
> >> mainline kernel isn't fit to exist at all."
> > 
> > What kind of code is not accepted into the mainline kernel tree for good
> > reasons?
> 
> - proprietary code

It's unclear whether distributing not GPL compatible modules is legal
at all.

And they are definitely not "very good reasons" for doing anything in 
the kernel.

> - unmaintained code

Unmaintained code in the kernel has a realistic chance of being usable 
for 5 years.

Unmaintained external code is quite likely to be unusable after
at most one year.

> - code conflicting with existing kernel structure or policy
> - code in which the concerned subsystem maintainers see no benefit

Let's fix the problems, not work around them.

There is a conflict between getting code included and ensuring some 
minimum quality of the kernel, but in many cases we could try better.

And when there's a good reason for a kernel policy, then code that
violates this policy is not a "very good reason" for anything.

> - code which its author is unable and/or unwilling to convert to
>   kernel coding standards
> - code whose author is unable and/or unwilling to defend it on LKML
>...

That's their fault, and definitely not a "very good reason" for making 
life easier for them.

> Thanks,
> Tilman

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

eradicating out of tree modules (was: : Linux Security *Module* Framework)

[Tilman Schmidt]

Adrian Bunk schrieb:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>>>> [...] Once you admit that there is code which, for very good
>>>> reasons, won't ever be accepted into the mainline kernel tree, what you
>>>> are saying amounts to: "Code that isn't fit to be included in the
>>>> mainline kernel isn't fit to exist at all."
>>> What kind of code is not accepted into the mainline kernel tree for good
>>> reasons?
>> - proprietary code
> 
> It's unclear whether distributing not GPL compatible modules is legal
> at all.

We're neither talking about distribution nor legal aspects, but
about existence. But anyway, you seem to agree with me that there
are very good reasons for not including these in the kernel.

> And they are definitely not "very good reasons" for doing anything in 
> the kernel.

There is a big difference between "not doing anything to help"
and "actively doing something to make life difficult for". The
former is undoubtedly legitimate. It's the latter we're
discussing here.

>> - unmaintained code
> 
> Unmaintained code in the kernel has a realistic chance of being usable 
> for 5 years.
> 
> Unmaintained external code is quite likely to be unusable after
> at most one year.

Then why is "being unmaintained" being toted as an argument
*against* inclusion in the kernel?

>> - code conflicting with existing kernel structure or policy
>> - code in which the concerned subsystem maintainers see no benefit
> 
> Let's fix the problems, not work around them.

That's certainly better, but not always possible. Do you
agree with me that if it isn't, then that's a very good
reason for not including that code in the kernel?

> There is a conflict between getting code included and ensuring some 
> minimum quality of the kernel, but in many cases we could try better.

Correct. Again, you appear to agree with my statement that
for some code there are very good reasons not to include it
in the kernel.

> And when there's a good reason for a kernel policy, then code that
> violates this policy is not a "very good reason" for anything.

>> - code which its author is unable and/or unwilling to convert to
>>   kernel coding standards
>> - code whose author is unable and/or unwilling to defend it on LKML
>> ...
> 
> That's their fault, and definitely not a "very good reason" for making 
> life easier for them.

Putting aside the fruitless question of whose fault it is,
is it a "very good reason" for actively making life more
difficult for them than it is already, eg. by gratuitiously
breaking interfaces they rely on for no other "very good
reason" than to discourage out-of-tree development? In other
words, do you think it benefits the Linux community if you
discourage those programmers you've already scared away from
submitting their code to the kernel from continuing their
work off-tree, too? In summary, do you think the world would
be a better place if all the existing out-of-tree modules
just ceased to exist, without any replacement?

T.

Re: eradicating out of tree modules

[Stefan Richter]

Tilman Schmidt wrote about:
> breaking interfaces they rely on for no other "very good
> reason" than to discourage out-of-tree development?

How often did this happen yet?
-- 
Stefan Richter
-=====-=-=== =-=- ==-==
http://arcgraph.de/sr/

Re: eradicating out of tree modules (was: : Linux Security *Module* Framework)

[Adrian Bunk]

On Sat, Oct 27, 2007 at 04:47:15PM +0200, Tilman Schmidt wrote:
> Adrian Bunk schrieb:
> > On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> >> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> >>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >>>> [...] Once you admit that there is code which, for very good
> >>>> reasons, won't ever be accepted into the mainline kernel tree, what you
> >>>> are saying amounts to: "Code that isn't fit to be included in the
> >>>> mainline kernel isn't fit to exist at all."
> >>> What kind of code is not accepted into the mainline kernel tree for good
> >>> reasons?
> >> - proprietary code
> > 
> > It's unclear whether distributing not GPL compatible modules is legal
> > at all.
> 
> We're neither talking about distribution nor legal aspects, but
> about existence. But anyway, you seem to agree with me that there
> are very good reasons for not including these in the kernel.
> 
> > And they are definitely not "very good reasons" for doing anything in 
> > the kernel.
> 
> There is a big difference between "not doing anything to help"
> and "actively doing something to make life difficult for". The
> former is undoubtedly legitimate. It's the latter we're
> discussing here.

Justifying anything with code with not GPL compatible licences has zero 
relevance here.

And there's value in making life harder for such modules with 
questionable legality. As an example, consider people who experienced 
crashes of "the Linux kernel" caused by some binary-only driver.
Not that uncommon e.g. with some graphics drivers.
This harms the reputation of Linux as being stable.

The solution is not to support proprietary drivers, the solution is to 
get open source replacements.

>...
> >> - code conflicting with existing kernel structure or policy
> >> - code in which the concerned subsystem maintainers see no benefit
> > 
> > Let's fix the problems, not work around them.
> 
> That's certainly better, but not always possible. Do you
> agree with me that if it isn't, then that's a very good
> reason for not including that code in the kernel?

No, it's still a reason for fixing the real problem.

> > There is a conflict between getting code included and ensuring some 
> > minimum quality of the kernel, but in many cases we could try better.
> 
> Correct. Again, you appear to agree with my statement that
> for some code there are very good reasons not to include it
> in the kernel.

But this does not result in any obligation of supporting low quality 
external code that destabilizes the kernel of people using it.

If it's low quality code doing something useful - well, how many hundred 
people are on Greg's list only waiting for some driver they could write?

> > And when there's a good reason for a kernel policy, then code that
> > violates this policy is not a "very good reason" for anything.
> 
> >> - code which its author is unable and/or unwilling to convert to
> >>   kernel coding standards
> >> - code whose author is unable and/or unwilling to defend it on LKML
> >> ...
> > 
> > That's their fault, and definitely not a "very good reason" for making 
> > life easier for them.
> 
> Putting aside the fruitless question of whose fault it is,
> is it a "very good reason" for actively making life more
> difficult for them than it is already, eg. by gratuitiously
> breaking interfaces they rely on for no other "very good
> reason" than to discourage out-of-tree development? In other
> words, do you think it benefits the Linux community if you
> discourage those programmers you've already scared away from
> submitting their code to the kernel from continuing their
> work off-tree, too? In summary, do you think the world would
> be a better place if all the existing out-of-tree modules
> just ceased to exist, without any replacement?

With your "without any replacement" you needlessly excluded the 
reasonable solution:

The solution is that someone other than the author either takes the 
existing external code or rewrites it from scratch, submits it for 
inclusion into the kernel, and maintains it there.

Let me repeat that Greg has said he has hundreds of volunteers for such 
tasks.

> T.

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: eradicating out of tree modules

[Stefan Richter]

Adrian Bunk wrote:
> On Sat, Oct 27, 2007 at 04:47:15PM +0200, Tilman Schmidt wrote:
>> There is a big difference between "not doing anything to help"
>> and "actively doing something to make life difficult for". The
>> former is undoubtedly legitimate. It's the latter we're
>> discussing here.
> 
> Justifying anything with code with not GPL compatible licences has zero 
> relevance here.
> 
> And there's value in making life harder for such modules with 
> questionable legality. As an example,
[...]

You two are hypothesizing.

  - We (most of us) change APIs to improve the kernel.

  - We (most of us) contribute to the kernel as a program for people to
    run, not as a library for other projects to develop different or
    extended kernels¹ on top of it.

Actually, by providing the code under GPL, full read access to the SCM
for everybody, and public development mailinglists, we make life for
external projects who do their own drivers and kernels as easy as these
unconnected projects could wish for.²

-----
¹) Even distributors of Linux kernel packages are encouraged to stay
close to mainline and to feed their changes into mainline, IOW to take
part in the Linux kernel project.

²) Of course if such projects chose to become part of the Linux kernel
project, they would get to enjoy additional bonuses as outlined at the
end of stable_api_nonsense.txt.  Sure, becoming part of the project
involves to cooperate, and not everybody wants or can afford to do so.
-- 
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/

Re: eradicating out of tree modules

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Am 28.10.2007 10:25 schrieb Stefan Richter:
> You two are hypothesizing.

No, we're not. We're discussing the very real issue of whether
LSM should be amputated in such a way as to make life difficult
for out of tree security module developers.

>   - We (most of us) change APIs to improve the kernel.

That's good. If that was consensus then this discussion would
not be necessary. What I am protesting against is attempts to
change the API purposely to obstruct out-of-tree code. That is
not a way to improve the kernel.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: eradicating out of tree modules

[Stefan Richter]

Tilman Schmidt wrote:
> Am 28.10.2007 10:25 schrieb Stefan Richter:
>> You two are hypothesizing.
> 
> No, we're not. We're discussing the very real issue of whether
> LSM should be amputated in such a way as to make life difficult
> for out of tree security module developers.

I still believe you are.  From what I understood, the API change had
technical reasons.  (What I have read is that using security modules in
the form of loadable and unloadable kernel modules didn't make sense.)
-- 
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/

Re: eradicating out of tree modules

[Simon Arlott]

On 28/10/07 14:37, Stefan Richter wrote:
> Tilman Schmidt wrote:
>> Am 28.10.2007 10:25 schrieb Stefan Richter:
>>> You two are hypothesizing.
>> 
>> No, we're not. We're discussing the very real issue of whether
>> LSM should be amputated in such a way as to make life difficult
>> for out of tree security module developers.
> 
> I still believe you are.  From what I understood, the API change had
> technical reasons.  (What I have read is that using security modules in
> the form of loadable and unloadable kernel modules didn't make sense.)

Stacking modules makes a lot of sense, it may be tricky to order sensibly, 
now if you want the features of more than one LSM (including those being 
added to the kernel), you need to *copy* the parts you want. Since you 
can't use modules to load them, because that feature's been removed, you 
need to maintain your own kernel tree for it or submit your changes which 
will eventually end up with LSMs that all do the same thing...

This static LSM doesn't even make sense to me - what happens if I select 
both SECURITY_CAPABILITIES and SECURITY_ROOTPLUG? I can't easily check 
because I'm using 2.6.23 - so I can still reload my module while changing 
it to have a better configuration interface. Kconfig doesn't look like it 
will prevent it. Surely the options should be a multiple choice menu?


Adrian's mentioned people eager to write drivers - LSMs aren't drivers, 
there's really nothing to work from except "security module that does X" 
and for that people should develop what they want themselves.

There's no reason for out of tree *GPL* drivers to not exist, is there?
How much of the non-driver code that gets merged into the kernel exists 
first as out of tree modules, rather than direct patches to the tree 
itself? It was made much easier since 2.4 to compile a module out of tree 
using a simple Makefile. (Perhaps that should be removed too?)

-- 
Simon Arlott

Re: eradicating out of tree modules

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

Am 28.10.2007 15:37 schrieb Stefan Richter:
> Tilman Schmidt wrote:
>> Am 28.10.2007 10:25 schrieb Stefan Richter:
>>> You two are hypothesizing.
>> No, we're not. We're discussing the very real issue of whether
>> LSM should be amputated in such a way as to make life difficult
>> for out of tree security module developers.
> 
> I still believe you are.  From what I understood, the API change had
> technical reasons.  (What I have read is that using security modules in
> the form of loadable and unloadable kernel modules didn't make sense.)

The jury is still out on that, and it's not my area of expertise
anyway. But Adrian declared that making life more difficult for
out-of-tree module developers would in itself be a legitimate
reason for such a change, and that's what I'm disputing.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: eradicating out of tree modules

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 3214 bytes --]

Am 28.10.2007 02:55 schrieb Adrian Bunk:
> Justifying anything with code with not GPL compatible licences has zero 
> relevance here.
> 
> And there's value in making life harder for such modules with 
> questionable legality. As an example, consider people who experienced 
> crashes of "the Linux kernel" caused by some binary-only driver.
> Not that uncommon e.g. with some graphics drivers.
> This harms the reputation of Linux as being stable.

You are mixing up several distinct categories here: "out of tree"
!= "non-GPL" != "proprietary" != "of questionable legality" !=
"binary-only" != "causing kernel crashes".

> The solution is not to support proprietary drivers, the solution is to 
> get open source replacements.

So how do you propose to "get" those replacements? And what shall
users do during the time this "getting" may take?

> If it's low quality code doing something useful - well, how many hundred 
> people are on Greg's list only waiting for some driver they could write?

No idea. Obviously not enough to actually solve the problem.
What solution do you propose?

>> [D]o you think the world would
>> be a better place if all the existing out-of-tree modules
>> just ceased to exist, without any replacement?
> 
> With your "without any replacement" you needlessly excluded the 
> reasonable solution:
> 
> The solution is that someone other than the author either takes the 
> existing external code or rewrites it from scratch, submits it for 
> inclusion into the kernel, and maintains it there.

My "without any replacement" is just a description of reality.
All current external code I am aware of continues to exist only
because there is no in-kernel replacement.

Again: how do you propose to bring that solution of yours to pass,
how long do you think it will take, and what do you propose current
users of out-of-tree modules do in the meantime?

Without reasonable answers to these questions, your proposed
solution itself hardly qualifies as reasonable.

> Let me repeat that Greg has said he has hundreds of volunteers for such 
> tasks.

Even with hundreds of volunteers, your proposed solution of just
rewriting *all* external code in a way fit for inclusion into the
kernel is an unachievable goal. Just look at the list on
http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
and try to answer why each of them is still out of tree.
Hint: In most cases it's neither out of malice nor stupidity on
the authors' part.

Of course in-tree code is always better than out-of-tree code. But
I maintain there will always be out-of-tree code (modules, drivers,
whatever) that fills a real need not (though hopefully, just not
yet) satisfied by any in-tree code. All I'm asking for is that you
take a pragmatic stance with regard to that: not going to any great
lengths to support it, but acknowledging its existence and
legitimacy - and not inciting to deliberately break it.

Thanks,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: eradicating out of tree modules

[Adrian Bunk]

On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
> Am 28.10.2007 02:55 schrieb Adrian Bunk:
> > Justifying anything with code with not GPL compatible licences has zero 
> > relevance here.
> > 
> > And there's value in making life harder for such modules with 
> > questionable legality. As an example, consider people who experienced 
> > crashes of "the Linux kernel" caused by some binary-only driver.
> > Not that uncommon e.g. with some graphics drivers.
> > This harms the reputation of Linux as being stable.
> 
> You are mixing up several distinct categories here: "out of tree"
> != "non-GPL" != "proprietary" != "of questionable legality" !=
> "binary-only" != "causing kernel crashes".

"binary-only non-GPL out-of-tree module causes kernel crashes" is a 
quite common pattern for some popular binary-only modules.

And noone except the vendor of this module can debug and fix it.

Include more than one binary-only module into your kernel and the number 
of people being able to debug it might drop to zero.

> > The solution is not to support proprietary drivers, the solution is to 
> > get open source replacements.
> 
> So how do you propose to "get" those replacements? And what shall
> users do during the time this "getting" may take?

They should swamp the hardware vendors with requests for releasing 
hardware specifications.

Or even better buy their hardware from a competitor.

> > If it's low quality code doing something useful - well, how many hundred 
> > people are on Greg's list only waiting for some driver they could write?
> 
> No idea. Obviously not enough to actually solve the problem.

Greg has just begins with getting this started.

> What solution do you propose?

You list the drivers you currently have in mind at the Linux Driver 
Project [1].

> >> [D]o you think the world would
> >> be a better place if all the existing out-of-tree modules
> >> just ceased to exist, without any replacement?
> > 
> > With your "without any replacement" you needlessly excluded the 
> > reasonable solution:
> > 
> > The solution is that someone other than the author either takes the 
> > existing external code or rewrites it from scratch, submits it for 
> > inclusion into the kernel, and maintains it there.
> 
> My "without any replacement" is just a description of reality.
> All current external code I am aware of continues to exist only
> because there is no in-kernel replacement.
> 
> Again: how do you propose to bring that solution of yours to pass,

You list the drivers you currently have in mind at the Linux Driver
Project [1].

> how long do you think it will take, and what do you propose current
> users of out-of-tree modules do in the meantime?

Noone proposed to make the existance of out-of-tree modules completely 
impossible - but it is a fact that derives directly from the Linux 
kernel development model that thre's no stable API for out-of-tree 
modules, and therefore each new kernel breaks many of them.

Once you accept this fundamental fact there's not much point in arguing 
that changes that break out-of-tree modules should be fewer.

>...
> > Let me repeat that Greg has said he has hundreds of volunteers for such 
> > tasks.
> 
> Even with hundreds of volunteers, your proposed solution of just
> rewriting *all* external code in a way fit for inclusion into the
> kernel is an unachievable goal. Just look at the list on
> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
> and try to answer why each of them is still out of tree.
> Hint: In most cases it's neither out of malice nor stupidity on
> the authors' part.

There are different problems why different drivers are not (yet) 
included in the kernel, but which ones don't have any possible solution?

And if you compare the numbers you'll see that Greg has on average a 
handful of volunteers for one driver.

> Of course in-tree code is always better than out-of-tree code. But
> I maintain there will always be out-of-tree code (modules, drivers,
> whatever) that fills a real need not (though hopefully, just not
> yet) satisfied by any in-tree code. All I'm asking for is that you
> take a pragmatic stance with regard to that: not going to any great
> lengths to support it, but acknowledging its existence and
> legitimacy - and not inciting to deliberately break it.

The most important question is still:

Why should there always be out-of-tree code that fills a real need not 
satisfied by any in-tree code?

Not everything might have worked in an ideal way in the past, but let's 
try to fix the problem, not let the problem justify workarounds.

> Thanks,
> Tilman

cu
Adrian

[1] http://linuxdriverproject.org

-- 

       "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: eradicating out of tree modules

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 5545 bytes --]

Am 28.10.2007 20:25 schrieb Adrian Bunk:
> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>> Justifying anything with code with not GPL compatible licences has zero 
>>> relevance here.
>>>
>>> And there's value in making life harder for such modules with 
>>> questionable legality. As an example, consider people who experienced 
>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>> Not that uncommon e.g. with some graphics drivers.
>>> This harms the reputation of Linux as being stable.
>> You are mixing up several distinct categories here: "out of tree"
>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>> "binary-only" != "causing kernel crashes".
> 
> "binary-only non-GPL out-of-tree module causes kernel crashes" is a 
> quite common pattern for some popular binary-only modules.

Common, yes. Popular, maybe. The only one, not. Taking that as reason
for breaking out-of-tree open source modules is throwing out the baby
with the bathwater.

>>> The solution is not to support proprietary drivers, the solution is to 
>>> get open source replacements.
>> So how do you propose to "get" those replacements? And what shall
>> users do during the time this "getting" may take?
> 
> They should swamp the hardware vendors with requests for releasing 
> hardware specifications.

They are doing that already. But somehow it fails to magically cause
open source drivers to spring into existence immediately. The crucial
word here is *time*.

> Or even better buy their hardware from a competitor.

Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
I thought that was a Microsoft line. (SCNR)

>>> If it's low quality code doing something useful - well, how many hundred 
>>> people are on Greg's list only waiting for some driver they could write?
>> No idea. Obviously not enough to actually solve the problem.
> 
> Greg has just begins with getting this started.

Exactly. Again, the problem is time. Deliberately breaking external
modules now and promising an in-tree alternative for later leaves
users out in the cold. That won't do much to improve the reputation
of Linux.

>> What solution do you propose?
> 
> You list the drivers you currently have in mind at the Linux Driver 
> Project [1].

They are all there already.

> Noone proposed to make the existance of out-of-tree modules completely 
> impossible - but it is a fact that derives directly from the Linux 
> kernel development model that thre's no stable API for out-of-tree 
> modules, and therefore each new kernel breaks many of them.

Granted.

> Once you accept this fundamental fact there's not much point in arguing 
> that changes that break out-of-tree modules should be fewer.

Granted. But that's not the point I was arguing anyway.

There is still a point in arguing that breaking out-of-tree modules
is not a goal. It's acceptable collateral damage if there is a good
reason for a change, but it doesn't by and in itself constitute such
a reason. That's why I'm taking exception with your statement in
<20071024223124.GI30533@stusta.de>:
> [...] even though it might sound harsh breaking 
> external modules and thereby making people aware that their code should 
> get into the kernel is IMHO a positive point.

Breaking external modules is *not* positive. It's acceptable, but
everything else being equal it's still better to avoid it.

>>> Let me repeat that Greg has said he has hundreds of volunteers for such 
>>> tasks.
>> Even with hundreds of volunteers, your proposed solution of just
>> rewriting *all* external code in a way fit for inclusion into the
>> kernel is an unachievable goal. Just look at the list on
>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>> and try to answer why each of them is still out of tree.
>> Hint: In most cases it's neither out of malice nor stupidity on
>> the authors' part.
> 
> There are different problems why different drivers are not (yet) 
> included in the kernel, but which ones don't have any possible solution?

I'm convinced all of them have possible solutions. The challenge
is to turn a possible solution into an actual one. And again, the
problem is time.

> And if you compare the numbers you'll see that Greg has on average a 
> handful of volunteers for one driver.

Not every problem can be solved faster by throwing more people at
it. Take mISDN as an example. Its developers have stated the goal
of inclusion in the main kernel tree years ago and it's still not
there. Deliberately breaking this external module "to make people
aware that their code should get into the kernel" would only delay
this goal even more. But sending them a handful of new volunteers
now would probably constitute the proverbial "adding manpower to a
late project".

> The most important question is still:
> 
> Why should there always be out-of-tree code that fills a real need not 
> satisfied by any in-tree code?

Because every in-tree code starts as out-of-tree code, so as long
as there's development at all there's always a certain amount of
code which isn't in-tree yet - or of which it isn't even sure yet
whether it will get in-tree.

HTH

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: eradicating out of tree modules

[linux-os (Dick Johnson)]

On Mon, 29 Oct 2007, Tilman Schmidt wrote:

> Am 28.10.2007 20:25 schrieb Adrian Bunk:
>> On Sun, Oct 28, 2007 at 07:51:12PM +0100, Tilman Schmidt wrote:
>>> Am 28.10.2007 02:55 schrieb Adrian Bunk:
>>>> Justifying anything with code with not GPL compatible licences has zero
>>>> relevance here.
>>>>
>>>> And there's value in making life harder for such modules with
>>>> questionable legality. As an example, consider people who experienced
>>>> crashes of "the Linux kernel" caused by some binary-only driver.
>>>> Not that uncommon e.g. with some graphics drivers.
>>>> This harms the reputation of Linux as being stable.
>>> You are mixing up several distinct categories here: "out of tree"
>>> != "non-GPL" != "proprietary" != "of questionable legality" !=
>>> "binary-only" != "causing kernel crashes".
>>
>> "binary-only non-GPL out-of-tree module causes kernel crashes" is a
>> quite common pattern for some popular binary-only modules.
>
> Common, yes. Popular, maybe. The only one, not. Taking that as reason
> for breaking out-of-tree open source modules is throwing out the baby
> with the bathwater.
>
>>>> The solution is not to support proprietary drivers, the solution is to
>>>> get open source replacements.
>>> So how do you propose to "get" those replacements? And what shall
>>> users do during the time this "getting" may take?
>>
>> They should swamp the hardware vendors with requests for releasing
>> hardware specifications.
>
> They are doing that already. But somehow it fails to magically cause
> open source drivers to spring into existence immediately. The crucial
> word here is *time*.
>
>> Or even better buy their hardware from a competitor.
>
> Hmmm. "Your existing hardware isn't supported anymore, buy new one?"
> I thought that was a Microsoft line. (SCNR)
>
>>>> If it's low quality code doing something useful - well, how many hundred
>>>> people are on Greg's list only waiting for some driver they could write?
>>> No idea. Obviously not enough to actually solve the problem.
>>
>> Greg has just begins with getting this started.
>
> Exactly. Again, the problem is time. Deliberately breaking external
> modules now and promising an in-tree alternative for later leaves
> users out in the cold. That won't do much to improve the reputation
> of Linux.
>
>>> What solution do you propose?
>>
>> You list the drivers you currently have in mind at the Linux Driver
>> Project [1].
>
> They are all there already.
>
>> Noone proposed to make the existance of out-of-tree modules completely
>> impossible - but it is a fact that derives directly from the Linux
>> kernel development model that thre's no stable API for out-of-tree
>> modules, and therefore each new kernel breaks many of them.
>
> Granted.
>
>> Once you accept this fundamental fact there's not much point in arguing
>> that changes that break out-of-tree modules should be fewer.
>
> Granted. But that's not the point I was arguing anyway.
>
> There is still a point in arguing that breaking out-of-tree modules
> is not a goal. It's acceptable collateral damage if there is a good
> reason for a change, but it doesn't by and in itself constitute such
> a reason. That's why I'm taking exception with your statement in
> <20071024223124.GI30533@stusta.de>:
>> [...] even though it might sound harsh breaking
>> external modules and thereby making people aware that their code should
>> get into the kernel is IMHO a positive point.
>
> Breaking external modules is *not* positive. It's acceptable, but
> everything else being equal it's still better to avoid it.
>
>>>> Let me repeat that Greg has said he has hundreds of volunteers for such
>>>> tasks.
>>> Even with hundreds of volunteers, your proposed solution of just
>>> rewriting *all* external code in a way fit for inclusion into the
>>> kernel is an unachievable goal. Just look at the list on
>>> http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>>> and try to answer why each of them is still out of tree.
>>> Hint: In most cases it's neither out of malice nor stupidity on
>>> the authors' part.
>>
>> There are different problems why different drivers are not (yet)
>> included in the kernel, but which ones don't have any possible solution?
>
> I'm convinced all of them have possible solutions. The challenge
> is to turn a possible solution into an actual one. And again, the
> problem is time.
>
>> And if you compare the numbers you'll see that Greg has on average a
>> handful of volunteers for one driver.
>
> Not every problem can be solved faster by throwing more people at
> it. Take mISDN as an example. Its developers have stated the goal
> of inclusion in the main kernel tree years ago and it's still not
> there. Deliberately breaking this external module "to make people
> aware that their code should get into the kernel" would only delay
> this goal even more. But sending them a handful of new volunteers
> now would probably constitute the proverbial "adding manpower to a
> late project".
>
>> The most important question is still:
>>
>> Why should there always be out-of-tree code that fills a real need not
>> satisfied by any in-tree code?
>
> Because every in-tree code starts as out-of-tree code, so as long
> as there's development at all there's always a certain amount of
> code which isn't in-tree yet - or of which it isn't even sure yet
> whether it will get in-tree.
>
> HTH
>
> -- 
> Tilman Schmidt                          E-Mail: tilman@imap.cc
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Ungeÿÿffnet mindestens haltbar bis: (siehe Rÿÿckseite)

I'm sure that the majority of Linux users would never acquire
the 4-board assembly that we use to acquire X-Ray data and
generate real-time images for the baggage scanners in use
at the world's major airports. That assembly, containing
numerous CPUs and other high-speed pipelined stuff would
cost the user about  US$100,000 so I'm pretty sure that
are not many takers so it is very unlikely that any modules
to support it would never get into the mainstream kernel.

If we can't build out-of-tree modules to support this stuff,
then we can't use Linux. Already, we've complied with the
GPL terms that we will give our module code to anybody,
even though it is useless without our hardware which I'm
certain they are not going to buy.

Linux is NOT just a desk-top OS. It has many other uses.
It should scare the hell out of everybody to know that
Windows CE is being used in Aircraft flight directors.
We need to maintain the viability of Linux in dedicated
or embedded operations so that it will eventually replace
such stuff. Over the years, there has been a continual
attempt to obfuscate Linux to make it more difficult to
use out-of-tree. Further, the continual internal changes,
which don't affect anything but compatibility and the
ability to compile (changes for the sake of changes),
has caused many engineers to lose all their hair. Stop!
This has gone far enough. Right now we cannot upgrade
past linux-2.6.16.24 just because some kernel hacker
decided so. This is bad, real bad.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: eradicating out of tree modules

[Xavier Bestel]

On Tue, 2007-10-30 at 09:11 -0400, linux-os (Dick Johnson) wrote:
> I'm sure that the majority of Linux users would never acquire
> the 4-board assembly that we use to acquire X-Ray data and
> generate real-time images for the baggage scanners in use
> at the world's major airports. That assembly, containing
> numerous CPUs and other high-speed pipelined stuff would
> cost the user about  US$100,000 so I'm pretty sure that
> are not many takers so it is very unlikely that any modules
> to support it would never get into the mainstream kernel.

As long as you're maintaining them proprely, I don't why.

	Xav

Re: eradicating out of tree modules

[Greg KH]

On Tue, Oct 30, 2007 at 09:11:11AM -0400, linux-os (Dick Johnson) wrote:
> I'm sure that the majority of Linux users would never acquire
> the 4-board assembly that we use to acquire X-Ray data and
> generate real-time images for the baggage scanners in use
> at the world's major airports. That assembly, containing
> numerous CPUs and other high-speed pipelined stuff would
> cost the user about  US$100,000 so I'm pretty sure that
> are not many takers so it is very unlikely that any modules
> to support it would never get into the mainstream kernel.

Of course it would be accepted, hell, we have a whole sub-architecture
with what, 3 users?  :)

So please submit patches for your drivers, and we will be glad to review
them.

thanks,

greg k-h

Out-of-tree modules [was: Linux Security *Module* Framework]

[Jan Engelhardt]

On Oct 25 2007 19:56, Greg KH wrote:

>What kind of code is not accepted into the mainline kernel tree for good
>reasons?  What are these reasons?  What specific code are you talking
>about?
>
>I'm trying to compile a list of all known external modules and drivers
>and work to get them included in the main kernel tree to help prevent
>these kinds of things.  If you know of any that are not on the list at:
>	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>please feel free to add them, or email me with the needed information
>and I will add them to the list.


quad_dsp - http://jengelh.hopto.org/p/quad_dsp/

Provides a /dev/dsp style node for legacy applications that support 
neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.


thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff

Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after 
5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )

Re: Out-of-tree modules [was: Linux Security *Module* Framework]

[Lee Revell]

On 10/29/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>
> Provides a /dev/dsp style node for legacy applications that support
> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>

(I think that should read "AND more than 2 channel sound")

Couldn't ALSA's OSS emulation be extended to support more than 2
channels per device node?

>
> thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>
> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )

It looks like this could be trivially fixed in a mergeable way.  That
LKML thread petered out before the problem was seriously analyzed.

Did you try the -Z flag of hdparm?

Lee

Re: Out-of-tree modules [was: Linux Security *Module* Framework]

[Jan Engelhardt]

On Oct 29 2007 20:46, Lee Revell wrote:
>On 10/29/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
>> quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
>>
>> Provides a /dev/dsp style node for legacy applications that support
>> neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
>>
>
>(I think that should read "AND more than 2 channel sound")

It is for programs that only give out 2 channels of audio data.
Qdsp_dpl2 is a node that applies the DPL2 matrix on these two channels,
yielding the rear 2 channels, giving some sort of surround effect.

>Couldn't ALSA's OSS emulation be extended to support more than 2
>channels per device node?

I figured that exceeded my skills at that time.

>> thkd - ftp://ftp5.gwdg.de/pub/linux/misc/suser-jengelh/kernel/linux-2.6.23.1-ccj58/thkd.diff
>>
>> Workaround for Toshiba MK2003GAH hard-drive head auto-unloading after
>> 5-15 seconds. (Ref: http://lkml.org/lkml/2006/11/15/100 )
>
>It looks like this could be trivially fixed in a mergeable way.  That
>LKML thread petered out before the problem was seriously analyzed.
>
>Did you try the -Z flag of hdparm?

IIRC, yes, been through all sorts of hdparm options. -Z did not help
at all, and -B only prolonged the delay from 5 to around 15 seconds.
I contacted Tosh Corp (before posting on lkml) and while they know of
the 'issue', I did not get a satisfactory answer (namely how to FIX
it), so I thought why spend time slapping if there's a workaround...

Causing a minimal head seek every now and then (4096 bytes per 3
seconds is a somewhat small block size with a not-too-low interval)
is a working workaround for now. The module code is not top notch,
but I doubt I'll ever have more than one 1.8" MK2003GAH disk in the
same laptop.

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

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 21 2007 08:57, James Morris 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 looked at commit 20510f2f4e2dabb0ff6c13901807627ec9452f98
[havenot done much kernel activity recently] where you
transform the security interface, and what I see is that
all the static inline functions are replaced by an extern one, with the
same content. That actually seems to include more performance hit
than the (un)registering fluff. Why is that, actually?

Re: LSM conversion to static interface

[Giacomo Catenazzi]

Jan Engelhardt wrote:

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

> 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.)

But his is against LSM design (and first agreements about LSM):
LSM can deny rights, but it should not give extra permissions
or bypass standard unix permissions.

ciao
	cate

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>
>> I do have a pseudo LSM called "multiadm" at 
>> http://freshmeat.net/p/multiadm/ , quoting:
>
>> 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.)
>
>But his is against LSM design (and first agreements about LSM):
>LSM can deny rights, but it should not give extra permissions
>or bypass standard unix permissions.

It is just not feasible to add ACLs to all million files in /home,
also because ACLs are limited to around 25 entries.
And it is obvious I do not want <prof> to have UID 0, because
then you cannot distinguish who created what file.
So the requirement to the task is to have unique UIDs.
The next logical step would be to give capabilities to those UIDs.

*Is that wrong*? Who says that only UID 0 is allowed to have
all 31 capability bits turned on, and that all non-UID 0 users
need to have all 31 capability bits turned off?

So, we give caps to the subadmins (which is IMHO a natural task),
and then, as per LSM design (wonder where that is written) deny
some of the rights that the capabilities raised for subadmins grant,
because that is obviously too much.

Re: LSM conversion to static interface

[Giacomo A. Catenazzi]

Jan Engelhardt wrote:
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>>> I do have a pseudo LSM called "multiadm" at 
>>> http://freshmeat.net/p/multiadm/ , quoting:
>>> 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.)
>> But his is against LSM design (and first agreements about LSM):
>> LSM can deny rights, but it should not give extra permissions
>> or bypass standard unix permissions.
> 
> It is just not feasible to add ACLs to all million files in /home,
> also because ACLs are limited to around 25 entries.
> And it is obvious I do not want <prof> to have UID 0, because
> then you cannot distinguish who created what file.
> So the requirement to the task is to have unique UIDs.
> The next logical step would be to give capabilities to those UIDs.
> 
> *Is that wrong*? Who says that only UID 0 is allowed to have
> all 31 capability bits turned on, and that all non-UID 0 users
> need to have all 31 capability bits turned off?
> 
> So, we give caps to the subadmins (which is IMHO a natural task),
> and then, as per LSM design (wonder where that is written) deny
> some of the rights that the capabilities raised for subadmins grant,
> because that is obviously too much.

Nothing wrong.  I only said that it was against (IIRC) the
principle of LSM in kernel (we should only remove capacities).
I've nothing against the changing the design or rules.
It was only a commentary, to be sure that we know what we do ;-)

ciao
	cate

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote:
>> So, we give caps to the subadmins (which is IMHO a natural task),
>> and then, as per LSM design (wonder where that is written) deny
>> some of the rights that the capabilities raised for subadmins grant,
>> because that is obviously too much.
>
> Nothing wrong.  I only said that it was against (IIRC) the
> principle of LSM in kernel (we should only remove capacities).

Leave my capacitance alone! :)
[i hope you get the joke]

Anyway - I see your point. But what would give the user the capabilities
in the first place, if not a security module that implements this-and-that
capability-raising scheme?

Re: LSM conversion to static interface

[Serge E. Hallyn]

Quoting Jan Engelhardt (jengelh@computergmbh.de):
> 
> On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
> >
> >> I do have a pseudo LSM called "multiadm" at 
> >> http://freshmeat.net/p/multiadm/ , quoting:
> >
> >> 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.)
> >
> >But his is against LSM design (and first agreements about LSM):
> >LSM can deny rights, but it should not give extra permissions
> >or bypass standard unix permissions.
> 
> It is just not feasible to add ACLs to all million files in /home,
> also because ACLs are limited to around 25 entries.
> And it is obvious I do not want <prof> to have UID 0, because
> then you cannot distinguish who created what file.
> So the requirement to the task is to have unique UIDs.
> The next logical step would be to give capabilities to those UIDs.
> 
> *Is that wrong*? Who says that only UID 0 is allowed to have
> all 31 capability bits turned on, and that all non-UID 0 users
> need to have all 31 capability bits turned off?
> 
> So, we give caps to the subadmins (which is IMHO a natural task),
> and then, as per LSM design (wonder where that is written) deny
> some of the rights that the capabilities raised for subadmins grant,
> because that is obviously too much.

Once the per-process capability bounding set is accepted
(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
like:

	1. Create user 'jdoe' with uid 0
	2. write a pam module which, when jdoe logs in, takes
	   CAP_NET_ADMIN out of his capability bounding set
	3. Now jdoe can log in with the kind of capabilities subset
	   you describe.

It's not a perfect solution, since it doesn't allow jdoe any way at all
to directly execute a file with more caps (setuid and file capabilities
are subject to the capbound).  So there is certainly still a place for
multiadm.

-serge

Re: LSM conversion to static interface

[Jan Engelhardt]

On Oct 23 2007 10:20, Serge E. Hallyn wrote:
>
>Once the per-process capability bounding set is accepted
>(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
>like:
>
>	1. Create user 'jdoe' with uid 0

UID 0 is _not_ acceptable for me.

>	2. write a pam module which, when jdoe logs in, takes
>	   CAP_NET_ADMIN out of his capability bounding set
>	3. Now jdoe can log in with the kind of capabilities subset
>	   you describe.

It is not that easy.
CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security
checks in kernel code, and then the detailed implementation of
limitation is done inside multiadm.
This is not just raising or lowering capabilities.

>It's not a perfect solution, since it doesn't allow jdoe any way at all
>to directly execute a file with more caps (setuid and file capabilities
>are subject to the capbound).  So there is certainly still a place for
>multiadm.

A normal user can execute suid binaries today, and so can s/he with mtadm.
I do not see where that will change - it does not need any caps atm.

Re: LSM conversion to static interface

[Serge E. Hallyn]

Quoting Jan Engelhardt (jengelh@computergmbh.de):
> 
> On Oct 23 2007 10:20, Serge E. Hallyn wrote:
> >
> >Once the per-process capability bounding set is accepted
> >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something
> >like:
> >
> >	1. Create user 'jdoe' with uid 0
> 
> UID 0 is _not_ acceptable for me.

I'm aware.

> >	2. write a pam module which, when jdoe logs in, takes
> >	   CAP_NET_ADMIN out of his capability bounding set
> >	3. Now jdoe can log in with the kind of capabilities subset
> >	   you describe.
> 
> It is not that easy.
> CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security
> checks in kernel code, and then the detailed implementation of
> limitation is done inside multiadm.

You mean the read/write split?

> This is not just raising or lowering capabilities.

Nope, but it's related, and as I pointed out below it fits in pretty
nicely.

> >It's not a perfect solution, since it doesn't allow jdoe any way at all
> >to directly execute a file with more caps (setuid and file capabilities
> >are subject to the capbound).  So there is certainly still a place for
> >multiadm.
> 
> A normal user can execute suid binaries today, and so can s/he with mtadm.
> I do not see where that will change - it does not need any caps atm.

And he will still be able to *run* the suid binary, but if cap_bound is
reduced he won't be able to use capabilities taken out of the bounding
set, multiadm loaded or not.

-serge

Re: LSM conversion to static interface

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Tue, 23 Oct 2007 10:34:09 CDT, "Serge E. Hallyn" said:

> And he will still be able to *run* the suid binary, but if cap_bound is
> reduced he won't be able to use capabilities taken out of the bounding
> set, multiadm loaded or not.

I am willing to bet that there's still a *lot* of unaudited set[ug]id code
out there that's vulnerable to the same sorts of attacks as the one that
hit Sendmail a few back.  As such, I have to agree with your original
post of the patch that CAP_SYS_ADMIN should be required to lower the set,
as there's just too much danger of an exploit if users can create their
own reduced-set processes.

I'm debating whether we should have a printk if we detect that a removed
capability caused an -EPERM.  Yes, it can be used to spam the logs.  On the
other hand, I as the sysadmin would like to know if it's happening. Looks like
time for a sysctl or something....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: LSM conversion to static interface

[James Morris]

On Fri, 19 Oct 2007, Andreas Gruenbacher wrote:

> 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.

Can you provide an example of a real LSM which can be safely unloaded and 
also needs to be unloaded?

Why should we maintain infrastructure and extra complexity in the kernel 
for theoretical or unknown modules ?

Linus has asked for any valid out of tree users who need a dynamic 
interface to step forward.  Where are they?

As one of the people who actually maintains LSM (rather than simply 
speculates about it), I object to maintaining infrastructure which, to the 
best of my knowledge, is only used by out of tree, binary, broken junk.

If you recall, the original motivation for this patch was when the idea 
of adding a new capability to control security model unload was raised.  

That is, new security infrastructure was being proposed merely to cater to 
some other existing unnecessary security infrastructure.  So, rather than 
doing that, I proposed removing the unnecessary infrastructure.

I agree with Linus: if you can demonstrate a valid, concrete use for 
dynamic LSMs, then the infrastructure to support them can easily be 
reinstated.

But until then, it seems both reasonable and in keeping with good kernel 
development practices, to not maintain unused infrastructure.


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

Re: Re: LSM conversion to static interface

[Crispin Cowan]

To discuss how LSM should work, it would have been really helpful if the
OP had cc'd the LSM mailing list. I've cc'd the LSM list here ...

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.
>   
I did not speak up against this patch because it does not hurt AppArmor,
and I was trying to reduce the amount of LKML flaming that I engage in
:) but since you asked, IMHO this patch is extremely bad for Linux and
bad for Linux users.

The patch does have benefits, I just think those benefits are weak and
unimportant. It prohibits dynamic loading of security modules (you must
be compiled in) and prohibits unloading of security modules (because it
is unsafe, and potentially insecure). What makes these benefits weak and
unimportant is that you can have those benefits now without the patch by
just writing your module that way: if you think that a security module
should be compiled in and present when the kernel boots, and should
never be unloaded.

> 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..
>   
Why would you want to dynamically unload a module: because it is
convenient for debugging. Ok, so it is unsafe, and sometimes wedges your
kernel, which sometimes forces you to reboot. With this patch in place,
it forces you to *always* reboot when you want to try a hack to the module.

Why you would want to dynamically load a security module: because you
are an enterprise user, required to use a specific build of a kernel,
rather than compile your own kernel, but you also want to use (or even
try out) a security module that your enterprise's vendor of choice has
not chosen to bundle. In the current state, such a user can just go get
a module and use it. With this patch, such a user is just screwed, they
can't load and try the module without having to get into kernel building.

So the net impact of this patch is:

    * It takes a deployment practice (static compiled-in security) that
      is arguably good in many circumstances and makes it mandatory at
      all times.
    * It takes a development practice that is very convenient and
      slightly risky, and forces you into the pessimal inconvenient
      development practice at all times.
    * It prevents enterprise users, and in fact anyone who isn't
      comfortable compiling their own kernel, from ever trying out any
      security module that their distro vendor of choice did not ship.

This strikes me as a rather anti-choice position to take. It says that
because candy is bad for you, you only ever get to eat vegetables. I
don't understand why Linux would want to do this to its users.

It doesn't hurt me or AppArmor. Since AppArmor is now shipping with
SUSE, Ubuntu, and Mandriva, what this does is make it harder for newer
modules like TOMOYO, Multi-Admin, etc, to get exposure to enterprise
users. So I don't think I am being self-serving in arguing against this
patch. I just think it is bad for Linux.

Crispin

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

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

[Rob Meijer]

On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
>
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.

What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.

In a wider contect than just this list, it apears to me that MLS and
Obj Caps advocates simply dismiss the alternative models as broken or as
irrelevant at best. In my view this attitude is very much pressent on
the MLS list.

It might in the light of this attitude even be a viable option to just
simply spin off 3 (or more) sets of LSM module sets, and maybe even put
some ifdefs in the base code depending on the chosen access controll model,
if for some reason the 'model' warants some major patch.

To me it would look like a good concept if LSM/Linux would try to support
all exisiting formal models of access controll, but without the need to
support all implementation alternatives for these models. That is, if a
module 'requires' a patch but the underlaying formal model does not, than
it would seem reasonable that the module be fixed. If however the 'model'
seems to require the patch, it may be perfectly reasonable for this patch
to be implemented, if need be with an ifdef for the used model.

Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to first
think about what formal model they are actualy using, thus resulting in
cleaner module design.



Rob

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

[Crispin Cowan]

Rob Meijer wrote:
> What may be even more relevant are those concepts that couldn't be done
> in SELinux, and how proposals that come from the theory of alternative
> access controll models (like object capability modeling) are dismissed
> by the aparently largely MLS/MAC oriented people on the list.
Clearly what is needed here is for someone to actually implement an
object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor,
MultiADM, or TOMOYO can implement object capabilities, so there is clear
justification for building such a module. I would argue strongly to
include it.

> Thus IMHO it may be a good idea to instead of a maintainer for LSM
> modules as proposed, alternatively a maintainer for each formal model
> may be more appropriate. This also would require module builders to first
> think about what formal model they are actualy using, thus resulting in
> cleaner module design.
>   
I *really* dislike this idea. It seems to set up the situation that the
only acceptable modules are those that follow some "formal" model. Problems:

    * What qualifies as a formal model? This becomes an arbitrary litmus
      test, depending on whether the model was originally published in a
      sufficiently snooty forum.
    * What if someone invents a new model that has not been "formalized"
      yet? Should Linux be forced to wait until the idea has been
      through the academic mill before we allow someone to try
      implementing a module for the idea?
    * The proposal only allows a single implementation of each formal
      model. In theory, theory is just like practice, but in practice it
      is not. SMACK and SELinux follow substantially similar formal
      models (not exactly the same) so should we exclude one and keep
      the other? No, of course not, because in practice they are very
      different.

Crispin

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

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

[Peter Dolding]

On 10/29/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model. Problems:
>
>     * What qualifies as a formal model? This becomes an arbitrary litmus
>       test, depending on whether the model was originally published in a
>       sufficiently snooty forum.

Agree slows development and experimentation with a idea BAD.  I would
more say function and reach of model and how its ment to operate
documented clearly.  So next coder along is not taken wild guess.  It
must be so clearly documented that almost any system admin could
understand how much or how little protection it is providing.

>     * What if someone invents a new model that has not been "formalized"
>       yet? Should Linux be forced to wait until the idea has been
>       through the academic mill before we allow someone to try
>       implementing a module for the idea?

Experimental until documented out of tree following mine.
.
>     * The proposal only allows a single implementation of each formal
>       model. In theory, theory is just like practice, but in practice it
>       is not. SMACK and SELinux follow substantially similar formal
>       models (not exactly the same) so should we exclude one and keep
>       the other? No, of course not, because in practice they are very
>       different.

Drop a stick on both of them.   Since they both operate substantially
similar they should be directly prepared to share code with each
other.   If one is not prepared to work with the other openly and
fairly out the tree it goes.

It could quite simple become the only thing different between Smack
and Selinux in they way they read configuration files.   Long term the
most user friendly and security solid modules win.  So long term one
wins short term any number of models.  We of course wait for that to
happen.  Note it could be agreement between coders.   Since they were
force to work as one if there is merit it will come out.  There is no
room for empire builders.   We need security builders.  Part of that
is getting your code examined by the most number of people able.

Same with apparmor vs selinux both can provide file access filtering.
So why two sets of code to do it.

LSM need a really strong maintainer prepared to beat a few ears in.
Or all we will endup with is usable modules.   Selinux pain in but to
configure no not really usable.   Maybe flaws in Smack so force to use
Selinux.  Apparmor too weak.

Basically a stack of trash is the current LSM model.  LSM's are fast
turning into x86 vs x86-64 bitrot all over again accept this time 100
times worse.  What is basically bitrot caused by not sharing.
Stackable modules maybe.  More important shared source code to do
stuff and common standards between LSM used where able.  This also
should make it simpler for new models to be added and experimented
with.  Since the new model may not need to redo all there hooking
system all over again.  Reduced security risk more tested code used in
new models.

Next more important extend security down into applications if
applications need it.   File access filtering would be a great feature
at the thread level.

We have enough LSM's to be hard. It a privilege to be in the main
kernel tree not a right.  Part of having a module in the Linux kernel
tree is a promise to do what is right for everyones security using the
kernel even if it means the end to your LSM's existence.  Part of
doing what is right is sharing of code.   All LSM developers should be
looking at there code and asking should this be like posix file caps
and for everyone.  Or should this be a LSM only feature because its
useless to everyone else.  From what I am seeing LSM maintainers don't
seam to think its part of the requirement to help other LSM's be
better even if theirs ends up losing.  Only if you are building a
Empire does it matter who wins or loses the long term of LSM's.   Only
thing that truly matter is that we get the best long term.


Peter Dolding

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

[Rob Meijer]

On Mon, October 29, 2007 11:24, Crispin Cowan wrote:

>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>> modules as proposed, alternatively a maintainer for each formal model
>> may be more appropriate. This also would require module builders to
>> first
>> think about what formal model they are actualy using, thus resulting in
>> cleaner module design.
>>
> I *really* dislike this idea. It seems to set up the situation that the
> only acceptable modules are those that follow some "formal" model.
> Problems:
>
>     * What qualifies as a formal model? This becomes an arbitrary litmus
>       test, depending on whether the model was originally published in a
>       sufficiently snooty forum.
>     * What if someone invents a new model that has not been "formalized"
>       yet? Should Linux be forced to wait until the idea has been
>       through the academic mill before we allow someone to try
>       implementing a module for the idea?

I may have been stating things a bit to strong when talking only about
"formal" models only. But possibly you could just define the non-formal
experimental models as a single group.

The thing I was trying to propose was aimed at the problem that if someone
proposes a patch to the LSM base code that he/she feels is needed to
complete an LSM module that implements a particular (formal) model,
he/she would end up explaining and/or defending both the 'model', the module
and its requirement for the patch.

What I tried to propose is to assign some sort of maintainer role for each
(formal) model, and let these roles take care of the module/patch part of
stuff, while the module writer would only need to defend/discuss the the
patch with the model maintainer.

>     * The proposal only allows a single implementation of each formal
>       model. In theory, theory is just like practice, but in practice it
>       is not. SMACK and SELinux follow substantially similar formal
>       models (not exactly the same) so should we exclude one and keep
>       the other? No, of course not, because in practice they are very
>       different.

I would think the two may benefit from a role as described above.
But I was thinking more in the line of new modules that may again
implement this same model, and would thus benefit from interaction with
this 'model maintainer' role.


Rob

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

[Crispin Cowan]

Rob Meijer wrote:
> On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>   
>>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>>> modules as proposed, alternatively a maintainer for each formal model
>>> may be more appropriate. This also would require module builders to
>>> first
>>> think about what formal model they are actualy using, thus resulting in
>>> cleaner module design.
>>>       
>> I *really* dislike this idea. It seems to set up the situation that the
>> only acceptable modules are those that follow some "formal" model.
>> Problems:
>> ...
>>     * The proposal only allows a single implementation of each formal
>>       model. In theory, theory is just like practice, but in practice it
>>       is not. SMACK and SELinux follow substantially similar formal
>>       models (not exactly the same) so should we exclude one and keep
>>       the other? No, of course not, because in practice they are very
>>       different.
>>     
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.
>   
Ah! So the proposal really is to have an LSM maintainer for each
"family" of models, acting as a resource and arbiter for modules in a class.

I like that idea, and have no objection to it. However, it does have
resource problems, in that the pool of LSM maintainers is not that
large. There is also the likely objection that this degree of scale is
not needed until at least there are multiple families of models in the
upstream kernel, and possibly until there are multiple instances of a
single family in the upstream kernel.

It also begs the question of what constitutes a family.

    * AppArmor, SELinux, and TOMOYO are all ambient capability systems
          o AppArmor and TOMOYO are pathname based
          o SELinux is label based
    * SELinux and SMACK are label-based
          o I don't know if SMACK is an ambient capability system
    * Rob Meijer implicitly advocated for an object capability LSM
          o would it be pathname or label based? You could do either or
            both ...
    * The LSPP work from RH, Tresys, and TCS is MLS based
          o this is a subset of both label-based and ambient capability
            based
    * I have no clue what family to put MultiADM or Dazuko into
    * Getting very formal, I could imagine a Clarke-Wilson module
    * Getting very informal, I could imagine a module that is a
      collection of cute intrusion prevention hacks, such as the Open
      wall Linux symlink and hardlink restrictions, and my own RaceGuard
      work
          o Oh wait, I published
            <http://citeseer.ist.psu.edu/cowan01raceguard.html>
            RaceGuard. Does that make it formal? :-)

Crispin

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

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

[Peter Dolding]

On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> Ah! So the proposal really is to have an LSM maintainer for each
> "family" of models, acting as a resource and arbiter for modules in a class.

I see it a little bit different one LSM maintainer for the lot of
modules who kicks the ass's of thoses who are not prepaid to share.
>
> I like that idea, and have no objection to it. However, it does have
> resource problems, in that the pool of LSM maintainers is not that
> large. There is also the likely objection that this degree of scale is
> not needed until at least there are multiple families of models in the
> upstream kernel, and possibly until there are multiple instances of a
> single family in the upstream kernel.
>
> It also begs the question of what constitutes a family.
>
>     * AppArmor, SELinux, and TOMOYO are all ambient capability systems
>           o AppArmor and TOMOYO are pathname based
>           o SELinux is label based

Here as always all three should see where they can share code and get
the best performance this might mean AppArmor and Tomoyo use Selinux
labels because it causes less overhead.  Or Selinux provides a
optional path based using the other engine.  Both are providing the
same feature in different ways.   Question does have to be asked is
there bench testable justification for need two for file systems
filters.

>     * SELinux and SMACK are label-based
>           o I don't know if SMACK is an ambient capability system

Both of these are sharing backwards and forwards between each other so
being nice with each other.  LSM overall Maintainer only really need
to at worst way xyz sections are not merged/shared and to document why
with benchmarks if they are not going to be.  Ie tested reason.

>     * Rob Meijer implicitly advocated for an object capability LSM
>           o would it be pathname or label based? You could do either or
>             both ...
Both is a valid answer.   Sections done path based should be shared
with other path based and labal based shared with other label based.

>     * The LSPP work from RH, Tresys, and TCS is MLS based
>           o this is a subset of both label-based and ambient capability
>             based
Ok section by section where would it be best for that code base to share with.

>     * I have no clue what family to put MultiADM or Dazuko into
MultiADMIN falls under o my god head ache.  This is more a posix
standard feature altered ie 1 root user turned into many.  This really
risks breaking the other models as a LSM.  Its more of a all in or all
out.  Really it needs to be lowered out of LSM into a standard
optional Linux feature so it cannot breach the security of other LSM
modules.  Also LSM modules will need to be made able to tell a
MultiADMIN root users.  This is part of what I was talking about some
parts need to be as lower down module not at full blown LSM level.
This is the rare one where the complete model needs to be moved down.
There are bits in almost all LSM that need to be looked at being made
full time features of linux like quotas and posix file capability's .

Dazuko is the rare user mode controlled interface.  Still same rule
share code where able.  Anti-Virus integration and other protecting
systems are commonly overlooked by LSM's.    Same here if this should
be a LSM or a kernel optional feature independent to LSM that a LSM
can block from happening.

>     * Getting very formal, I could imagine a Clarke-Wilson module
>     * Getting very informal, I could imagine a module that is a
>       collection of cute intrusion prevention hacks, such as the Open
>       wall Linux symlink and hardlink restrictions, and my own RaceGuard
>       work
>           o Oh wait, I published
>             <http://citeseer.ist.psu.edu/cowan01raceguard.html>
>             RaceGuard. Does that make it formal? :-)
>
You will hate me but I don't call that formal enough.  Its lacks the
critical bit of doc written in terms that any system admin can
understand what they are being given.

Next question should RaceGuard be a LSM at all.  Or should it be a
standard feature what LSM can over rule? <Swap RaceGuard out standard
question for all new LSM's and LSM features>

Lot of things are being pushed as LSM's when they should be pushed as
expanded default features outside LSM.

Peter Dolding

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

[Jan Engelhardt]

(please do not drop Cc, or I would have lost this thread part if I had 
not been on lkml. And sometimes I am not because of the volume. Thanks.)

On Oct 30 2007 15:13, Peter Dolding wrote:
>On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
>
>>     * I have no clue what family to put MultiADM or Dazuko into
>
>MultiADMIN falls under o my god head ache.  This is more a posix
>standard feature altered ie 1 root user turned into many.  This really
>risks breaking the other models as a LSM.

I disagree.

Traditionally, Linux has given a process all capabilities when the
UID changed to 0 (either by setuid(2) or executing a SUID binary).
This has been relieved over the years, and right now with LSMs in the
field, it is possible to 'deactivate' this special case for UID 0.

SELinux does not have this special case for UID 0. Neither does it
seem to use capabilities (quick grep through the source). So
basically, all users are the same, and no one has capabilities by
default. Does SELinux thus break with other LSMs?

Now assume a SELinux system where all users have all capabilities
(and the policy that is in place restricts the use of these
capabilities then) -- should not be that unlikely. Does that break
with other LSMs?

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

[Casey Schaufler]

--- Jan Engelhardt <jengelh@computergmbh.de> wrote:

> 
> (please do not drop Cc, or I would have lost this thread part if I had 
> not been on lkml. And sometimes I am not because of the volume. Thanks.)
> 
> On Oct 30 2007 15:13, Peter Dolding wrote:
> >On 10/30/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> >
> >>     * I have no clue what family to put MultiADM or Dazuko into
> >
> >MultiADMIN falls under o my god head ache.  This is more a posix
> >standard feature altered ie 1 root user turned into many.  This really
> >risks breaking the other models as a LSM.
> 
> I disagree.
> 
> Traditionally, Linux has given a process all capabilities when the
> UID changed to 0 (either by setuid(2) or executing a SUID binary).
> This has been relieved over the years, and right now with LSMs in the
> field, it is possible to 'deactivate' this special case for UID 0.
> 
> SELinux does not have this special case for UID 0. Neither does it
> seem to use capabilities (quick grep through the source). So
> basically, all users are the same, and no one has capabilities by
> default. Does SELinux thus break with other LSMs?
> 
> Now assume a SELinux system where all users have all capabilities
> (and the policy that is in place restricts the use of these
> capabilities then) -- should not be that unlikely. Does that break
> with other LSMs?

As some of the early Smack discussions brought out, some LSMs
including Smack will be perfectly happy with the traditional
Linux privilege mechanisms (choice of root and/or capablities)
while others including SELinux will go their own ways. So long
as LSMs are self contained and strictly restrictive the
mechanisms they use to modulate their behavior shouldn't be an
issue. If SELinux chooses to turn its MLS controls off between
midnight and 3am I can't see how that would be Smack's business,
even if they were somehow stacked. Multiple LSMs has issues,
like what should security_secid_to_secctx() return to the audit
system, but privilege model shouldn't be one of them.


Casey Schaufler
casey@schaufler-ca.com

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

[Jan Engelhardt]

On Oct 30 2007 12:14, Casey Schaufler wrote:
>
>while others including SELinux will go their own ways. So long
>as LSMs are self contained and strictly restrictive the
>mechanisms they use to modulate their behavior shouldn't be an
>issue. If SELinux chooses to turn its MLS controls off between
>midnight and 3am I can't see how that would be Smack's business,
>even if they were somehow stacked. Multiple LSMs has issues,
>like what should security_secid_to_secctx() return to the audit
>system, but privilege model shouldn't be one of them.

I am with you on that. And for everybody who missed it: MultiAdmin
only grants rights at the same time commoncap does (e.g. on setuid
and bprm_set_security). And all modules DO work with commoncap, now
don't they?

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

[Peter Dolding]

Jan Engelhardt wrote:
> I disagree.
>
> Traditionally, Linux has given a process all capabilities when the
> UID changed to 0 (either by setuid(2) or executing a SUID binary).
> This has been relieved over the years, and right now with LSMs in the
> field, it is possible to 'deactivate' this special case for UID 0.
>   
> SELinux does not have this special case for UID 0. Neither does it
> seem to use capabilities (quick grep through the source). So
> basically, all users are the same, and no one has capabilities by
> default. Does SELinux thus break with other LSMs?
>
> Now assume a SELinux system where all users have all capabilities
> (and the policy that is in place restricts the use of these
> capabilities then) -- should not be that unlikely. Does that break
> with other LSMs?
>   
MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules 
are applied over using Selinux rules.  This is just the way it is 
stacking LSM's is Just not healthy you always risk on LSM breaking 
another.  Part of the reason why I have suggested a complete redesign of 
LSM.  To get away from this problem of stacking.

I see MultiAdmin purely in the class of posix file capabilities( Fine 
grained replacement to SUID).
This is a standard feature fix not part of LSM.  Note it can not replace 
all SUID bits due to some internals of applications design need to be 
changed to support posix file capabilities in particular not checking if 
running as UID 0.  Traditional  UID 0 is already optional for 
applications without  LSM's.

Posix file capabilities only applies to applications only.  MultiAdmin 
being the user mirror of Posix file capabilities.

MultiAdmin patch to the user side may allow more SUID bits to be killed 
off from the start line.  So increasing overall system security.

Of course MultiAdmin might end up two halfs.   One a standard feature 
that hands out capabilities to users that LSMs can overrule.  And one a 
user by user directory access control LSM directory control LSM less 
likely to cause problems.

I really don't see the need for a LSM stacking order.  Some features 
just should not be LSM's in my eyes.  MultiAdmin is one of them.

Traditional way has all ready been expanded for applications without 
LSM's.  So my call still stand O heck head ache rating.   Because its in 
the wrong place.  Particularly when you think people will want to use it 
stacked with other LSM's.   Stacking should be avoided where able.   
This means at least some of Multiadmin features just have to be done 
core kernel as a normal kernel module to avoid stacking and breaking the 
LSM.

Note posix file capabilities was developed as a LSM module too at first 
the point came where it was going to cause more trouble for other LSMs 
granting stuff in conflict.    Both Multiadmin and posix file 
capabilities share a lot in common.  Both developed in the wrong place.  
Both required to be else where.  Even there function is similar breaking 
down root powers and handing them out more effectively.  So in my eyes 
it is a pure Posix extension not a LSM.

Peter Dolding

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

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:

> MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are 
> applied over using Selinux rules.  This is just the way it is stacking LSM's 
> is Just not healthy you always risk on LSM breaking another.  Part of the 
> reason why I have suggested a complete redesign of LSM.  To get away from 
> this problem of stacking.

since the method of stacking hasn't been determined yet, you can't say 
this.

it would be possible for MultiAdmin to grant additional access, that 
SELinux then denies for it's own reasons.

if the SELinux policy is written so that it ignores capabilities, and 
instead just looks at uid0 then that policy is broken in a stacked 
environment, but it's the polciy that's broken, not the stacking.

yes, there will be interactions that don't make sense, but just becouse 
something can be used wrong doesn't mean that there aren't other cases 
where it can be used properly.

David Lang

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

[Peter Dolding]

On 10/31/07, david@lang.hm <david@lang.hm> wrote:
> On Wed, 31 Oct 2007, Peter Dolding wrote:
>
> > MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
> > applied over using Selinux rules.  This is just the way it is stacking LSM's
> > is Just not healthy you always risk on LSM breaking another.  Part of the
> > reason why I have suggested a complete redesign of LSM.  To get away from
> > this problem of stacking.
>
> since the method of stacking hasn't been determined yet, you can't say
> this.

I can because that is the current day problem. With many LSM's loaded
they stack completely as a complete mess and with problems.  They
fight with each other.  Lack of define on stacking equals big
problems.   Since you have not created a standard for stacking does
not stop the problem from existing.  Nice lack of planing when LSM
started or maybe its intentional.  When you need stacking its about
time you start moving things into the OS?

There is a way around the problem too without allowing LSM to stack.
Good advantage backward compatible  because your are not playing with
the LSM standard to do it so no LSM modules should need large
alterations.  At worse mirror extensions to handle the new OS feature.
 Posix File Capabilities provide the solution.   First done as a LSM
risked conflict.   Moved in as a operating system extension by by
conflict.  Fragments from LSM's should exactly move that way if they
expect to be overlapped by other models.

Lot of stacking problems can be avoided if segments are complete
standard extensions.
>
> it would be possible for MultiAdmin to grant additional access, that
> SELinux then denies for it's own reasons.
>
> if the SELinux policy is written so that it ignores capabilities, and
> instead just looks at uid0 then that policy is broken in a stacked
> environment, but it's the polciy that's broken, not the stacking.

That is not how current day always works.  MultiAdmin grants and that
can be the end of the treeing.   Selinux does not get asked if it
refuses it or not.  So no matter what was set in the Selinux policy it
may never get used.   Adding more layers is also bad for performance
to.  Treeing threw modules for rights is a really slow process.  As
like a posix feature extension.   Selinux/Other LSM's is at top of
allocation no flaw no bypass.

> yes, there will be interactions that don't make sense, but just becouse
> something can be used wrong doesn't mean that there aren't other cases
> where it can be used properly.
>
We are talking security here if its not order safe its not good.
MultiAdmin done as a posix feature extension is order safe.
MultiAdmin done as a LSM is not order safe.

System Admins are humans too.  Getting orders backwards does happen.
So should be avoided where able.

This completely avoids the need for adding another layer of stacking
and since built inside current day framework.  Does doing this risk
the end of LSM's as we know it yes it does.  Since it is not being
used as LSM were intended.  LSM is just a addon to standard OS
security what is either a testing ground for new features to secure
the OS that get build into the OS in time or as location for security
modules.

Somethings should be just done in the Standard OS security nothing to
do with LSM.

Little bit hard for some I guess to hear that LSM are not all
important and not all Security features should be done in them.  Some
should be done in the main OS security features.

Biggest current day problem with LSM is they have forgot that LSM is
only a testing ground or a zone for features that people will only
want some of the time.

MultiAdmin is a feature that can enhance means to Audit OS ie who did
what.  Enhance security hand outs and can be really handy with almost
any LSM on the system.  Its description of what it is sounds very much
like every other standard feature.

Lets end the bitrot.  Start having bits go into the main OS security
features where they should be.

Peter Dolding

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

[Casey Schaufler]

--- Peter Dolding <oiaohm@gmail.com> wrote:


> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.

Gawd. Sorry, but we lost that argument in 1986 and the situation
hasn't changed a bit since. Most people just don't want what we're
selling. Do you know why Unix was a success and MULTICS* a failure?
It's because Unix had mode bits and MULTICS had ACLs. Fortunately
for those of us who wear titles like "Security Expert" or "Trust
Technologist" with pride there are enough clinical paranoids in
positions of authority to keep the Trusted System niche from closing
up completely and hence supporting our Rock Star Lifestyles. The
good news is that the situation is no worse than that faced by
the people who are bringing you Infiniband or Itanium, neither of
which will ever be the life of the party either. Sure security is
important, but I learned (in college, and yes they had colleges
way back then) not to drink too much at parties I'd crashed.

LSM isn't all I want it to be either, but it's better than I ever
got in the Proprietary OS world, and that includes when the MLS
systems were bringing in $20million a pop. Trying to force features
that virtually no one wants into any system is a bad idea. If
you haven't read Man of LaMancha I strongly suggest you do so.
Or at least see the play, it's got some catchy songs.

-----
* If you don't know what MULTICS was you can buy me a beer and
  I'll tell you the whole story


Casey Schaufler
casey@schaufler-ca.com

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

[david]

On Wed, 31 Oct 2007, Peter Dolding wrote:

> On 10/31/07, david@lang.hm <david@lang.hm> wrote:
>> On Wed, 31 Oct 2007, Peter Dolding wrote:
>>
>>> MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are
>>> applied over using Selinux rules.  This is just the way it is stacking LSM's
>>> is Just not healthy you always risk on LSM breaking another.  Part of the
>>> reason why I have suggested a complete redesign of LSM.  To get away from
>>> this problem of stacking.
>>
>> since the method of stacking hasn't been determined yet, you can't say
>> this.
>
> I can because that is the current day problem. With many LSM's loaded
> they stack completely as a complete mess and with problems.  They
> fight with each other.  Lack of define on stacking equals big
> problems.   Since you have not created a standard for stacking does
> not stop the problem from existing.  Nice lack of planing when LSM
> started or maybe its intentional.  When you need stacking its about
> time you start moving things into the OS?

the lack of a stacking ability was deliberate (go back and read the 
archives). basicly no LSM was willing to admit that they weren't the 
be-all, end-all of security, so nobody was willing to consider that anyone 
would ever want anything else.

one method of doing the stacking would be for the LSM to not know about 
the stacking, but the kernel takes care of passing all requests through 
each LSM in order (if the LSMs can be staticly compiled the order should 
be able to be changed at compile time)

now, the existing policies for some LSM's may need to change, becouse 
they've been assuming that they only needed to check capabilities for 
UID=0, when they will now need to check them for everyone, but arguably, 
this was a bug masquerading as an optimization in the first place.

> There is a way around the problem too without allowing LSM to stack.
> Good advantage backward compatible  because your are not playing with
> the LSM standard to do it so no LSM modules should need large
> alterations.  At worse mirror extensions to handle the new OS feature.
> Posix File Capabilities provide the solution.   First done as a LSM
> risked conflict.   Moved in as a operating system extension by by
> conflict.  Fragments from LSM's should exactly move that way if they
> expect to be overlapped by other models.
>
> Lot of stacking problems can be avoided if segments are complete
> standard extensions.

which LSM gets to declare the standards?

>>
>> it would be possible for MultiAdmin to grant additional access, that
>> SELinux then denies for it's own reasons.
>>
>> if the SELinux policy is written so that it ignores capabilities, and
>> instead just looks at uid0 then that policy is broken in a stacked
>> environment, but it's the polciy that's broken, not the stacking.
>
> That is not how current day always works.  MultiAdmin grants and that
> can be the end of the treeing.   Selinux does not get asked if it
> refuses it or not.  So no matter what was set in the Selinux policy it
> may never get used.   Adding more layers is also bad for performance
> to.  Treeing threw modules for rights is a really slow process.  As
> like a posix feature extension.   Selinux/Other LSM's is at top of
> allocation no flaw no bypass.

only if the stacking mode permits this. if it always requires passing 
through all the layers then this wouldn't be a problem.

Besides which, the MultiAdmin authors would probably be willing to make 
the nessasary changes to their LSM to play nicely with others anyway (but 
good programming practice would dictate that you don't count on it, and 
arrange for the other modules to approve as well)

>> yes, there will be interactions that don't make sense, but just becouse
>> something can be used wrong doesn't mean that there aren't other cases
>> where it can be used properly.
>>
> We are talking security here if its not order safe its not good.
> MultiAdmin done as a posix feature extension is order safe.
> MultiAdmin done as a LSM is not order safe.

as things are currently written, it's not possible to stack, so there is 
no order. change how things are written and you can make them safe.

> System Admins are humans too.  Getting orders backwards does happen.
> So should be avoided where able.

the sysadmins need to be given enough rope, you don't know everything that 
they are trying to do, and you don't know what other LSMs going to do. so 
how can you possibly decide ahead of time what orders are safe?

> This completely avoids the need for adding another layer of stacking
> and since built inside current day framework.  Does doing this risk
> the end of LSM's as we know it yes it does.  Since it is not being
> used as LSM were intended.  LSM is just a addon to standard OS
> security what is either a testing ground for new features to secure
> the OS that get build into the OS in time or as location for security
> modules.
>
> Somethings should be just done in the Standard OS security nothing to
> do with LSM.
>
> Little bit hard for some I guess to hear that LSM are not all
> important and not all Security features should be done in them.  Some
> should be done in the main OS security features.
>
> Biggest current day problem with LSM is they have forgot that LSM is
> only a testing ground or a zone for features that people will only
> want some of the time.

no, LSM is not just for testing, LSM is an interface so that Linus doesn't 
need to pick the 'one true security model' and enforce it on everyone.

it's like freedom of religion, each religion belives that they are the one 
true path, but in exchange for the guarentee that they are not going to be 
percecuted, they reluctantly allow all other religions equal freedom. when 
religion passes from mearly strange to activly harmful (i.e. cults) you 
find the edge of the freedom.

similarly, LSMs need to accept the fact that some people don't want their 
flavor of security, so to avoid being thrown out entirely they need to 
allow other LSMs to exist, and use the same kernel hooks, even if they 
believe that the alturnatives are misguided. as long as an LSM is not 
activly harmful (as opposed to mearly being snake oil) it should be 
allowed.

> MultiAdmin is a feature that can enhance means to Audit OS ie who did
> what.  Enhance security hand outs and can be really handy with almost
> any LSM on the system.  Its description of what it is sounds very much
> like every other standard feature.
>
> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.

which bits into which security features? Good, knowledgable people can't 
agree on what's right.

ending the bitrot just requires accepting the LSMs into the kernel as 
first-class options, it doesn't require declaring any one LSM (or even any 
part of any one LSM) as being the 'one right way' to do something and 
force everyone to use that way.

David Lang

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

[Crispin Cowan]

Peter Dolding wrote:
> Lets end the bitrot.  Start having bits go into the main OS security
> features where they should be.
>   
Linus categorically rejected this idea, several times, very clearly.

He did so because the security community cannot agree on a
one-true-standard for what that OS security feature set should be. From
looking at this thread and many others, he is correct; there is no
consensus on what the feature set should be.

So you can wish for the "main OS security features" all you want, but it
is not going to happen without a miraculous degree of consensus abruptly
arising.

On the contrary, security, done well, is a tight fitting suit. It must
be tight, or it allows too much slack and attackers can exploit that. To
make it tight, it must be tailored to the situation at hand. That means
that there may *never* be a consensus on the "one true way", because it
could be that there is no "one true way". It could be that SMACK is best
in some cases, AppArmor in others, SELinux in others yet again, MLS in
others, etc. etc.

I agree with Casey; LSM may not be perfect, but it is a great deal more
consensus than I have seen anywhere else in the security community. Your
desire that AppArmor and SELinux should share code has already happened:
LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
TOMOYO, and MultiADM, etc.

It certainly can be improved, but it is not in need of wholesale
replacement, and especially not without a clear design that addresses
clearly stated problems that lots of people are having.

Crispin

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

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

[Peter Dolding]

On 10/31/07, Crispin Cowan <crispin@crispincowan.com> wrote:
> Peter Dolding wrote:
> > Lets end the bitrot.  Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community cannot agree on a
> one-true-standard for what that OS security feature set should be. From
> looking at this thread and many others, he is correct; there is no
> consensus on what the feature set should be.
>
> So you can wish for the "main OS security features" all you want, but it
> is not going to happen without a miraculous degree of consensus abruptly
> arising.
>
Not really.  Every time Linus has rejected is when people have tried
to thump complete models like Selinux into kernel as one huge mother
of a blocks without grounds.

MultiAdmin is different most other models.  Please look at Posix File
Capabilities.  Grounds and security advantages of that module was
proven while not fighting with other LSM means to do protection.
There are grounds for many admins in linux for tracking admin
alterations.  It falls into a cat of a feature request and security
feature.  Of course not all of MultiAdmin features will be suitable at
main OS security features.  Yes MultiAdmin will have to be happy to
break there code up to get the as there key feature to as many users
as able.  This is a difference UID 0 all powerful I guess everyone
here can agree that is not exactly good.  Not being able to trace who
did alterations as UID 0 is not good either.  Where does the other
frameworks deal with it.

The path is still open into kernel.  Complete models of course are
never going to make it.  100 percent consensus is not always required.
 Same reasons for Posix File Capabilities providing a segmented SUID
feature.  Applying the same Capabilities on a user by user base also
has equal advantages instead of having UID 0 or not UID 0.

Next important question why not look at segments to put forward
consensus.  This is something is not clearly being looked for.

100 percent consensus has never been true for every feature in Linux.

>On the contrary, security, done well, is a tight fitting suit. It must
>be tight, or it allows too much slack and attackers can exploit that.

I love that quote.  There is difference to tight fitting and covering
everything needed.  Ie tight fitting suit without pockets is going to
be a pain.

Main OS security features always made tight by the LSM.  Since they
are override able.

This can solve the stack problem to a point.   Of course not a perfect solution.

Chain passing threw LSM is not a solution.  Never will be.  A
applications on systems may require many different security models to
protect them.

Needing hooks everywhere with unlimited control provided at a single
interface does not look like a tight security model to me.  Makes LSM
look like the Ideal rootkit location.

LSM bundling hooks into security interfaces segments and reduces
threat.  Since each interface has rules and limitations.

Of course my ideas have not been fully documented out correct.   I am
not foolish my skills are not perfect.  The reason behind my ideas is
to get past the limitations of LSM.

The differences between LSMs get less different the closer you get to
the LSM interface.

Label vs path based is the biggest divide.   Including the config
system of modules makes merging hard.  Catch is Label and path based
both have there places.  Ie filesystem limitations(path based) and
speed(label based).  So both being side by side in the kernel I have
no issue with.  I really have to ask why selinux does not support path
based for the odd file systems that don't support labels and the
reverse with apparmor?  Is it that the developers have been building a
empire and not see the need for the others features so failing
completely to build the most powerful security framework.

Yes LSM is only a testing ground and for features that no everyone
wants.  ie Not everyone wants selinux apparmor... Models.  For things
like posix file capabilities its just a testing ground for features
before it moved into kernel full time.

LSM has two uses. Not one.

'one true security model' I am not talking about that with Multiadmin
main goal is a Security Feature it really does not make up a complete
model in its own right.  Different Admins with different capability's.
 Now the final form of Multiadmin who knows.  If we had file access
controls at the same level of control as posix file capabilities there
is a chance that Multiadmin core features could be done threw pam.
Lack of core features is forcing things into the LSM level that may
not need to be there.  Having users with permissions more limited to
filesystem would be useful.  There are small fragments of LSM that
have uses out side the LSM framework also what you are failing to
offer.

This is the problem with Multiadmin its existence is truly
questionable.   Why does it exist where it does.  Even why it exists
at all.  Same applies to apparmor.  Why does it exist should it exist
complete a LSM or should it be cut in two standard OS feature and a
LSM.   Apparmor style file control would be great at a application
level like posix file capabilities.

Note all the core features do make a security model in its own right.
 Wish to enhance that should be equal goal to making LSM's.  They key
thing to the core security model is flexibility.  So of course Linus
does not want to choose a new model he already had one.

Peter Dolding

PS This is most likely no what people want to hear.

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

[Toshiharu Harada]

2007/10/31, Crispin Cowan <crispin@crispincowan.com>:
> Peter Dolding wrote:
> > Lets end the bitrot.  Start having bits go into the main OS security
> > features where they should be.
> >
> Linus categorically rejected this idea, several times, very clearly.
>
> He did so because the security community cannot agree on a
> one-true-standard for what that OS security feature set should be. From
> looking at this thread and many others, he is correct; there is no
> consensus on what the feature set should be.
>
> So you can wish for the "main OS security features" all you want, but it
> is not going to happen without a miraculous degree of consensus abruptly
> arising.
>
> On the contrary, security, done well, is a tight fitting suit. It must
> be tight, or it allows too much slack and attackers can exploit that. To
> make it tight, it must be tailored to the situation at hand. That means
> that there may *never* be a consensus on the "one true way", because it
> could be that there is no "one true way". It could be that SMACK is best
> in some cases, AppArmor in others, SELinux in others yet again, MLS in
> others, etc. etc.
>
> I agree with Casey; LSM may not be perfect, but it is a great deal more
> consensus than I have seen anywhere else in the security community. Your
> desire that AppArmor and SELinux should share code has already happened:
> LSM *is* the sharable code base between AppArmor, SELinux, and SMACK and
> TOMOYO, and MultiADM, etc.

My main concern is whether we (different attempts) can share the code.
IOW whether we can reach and form the agreement for single security framework.
It is possible to write code if only we have a clear specifications, but
this is not the case.
I can easily think of LSM, or whatever we call,  as Greatest Common Factor,
but in that case LSM will explode soon and no single module can not be happy,
Linux security will not be achieved.

> It certainly can be improved, but it is not in need of wholesale
> replacement, and especially not without a clear design that addresses
> clearly stated problems that lots of people are having.

We should not invent wheels, that is agreed by everyone , but if we try to share
something that we can not share, we will fail. From the fact existing
LSM did not satisfy any module (including SELinux), I do not
want to investigate stack able version.

Cheers,
Toshiharu Harada

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

[Peter Dolding]

The Clear and Important thing is there is already a single security framework.

The single security framework is the security that exists when no LSM
is loaded.  It turns out the more I look most of my model already
exists just not being used effectively.  There is a capabilities frame
work at worse needs expanding to handling more detailed controls.
Like X thread can only read x y z files an write to a file.

Improvements to the single security framework are getting over looked.
  I would have personally though selinux would have done Posix file
capabilities as a general service to all.  But no IBM had to do it.
This shows a problem.  Critical upgrades to the single security
framework are not being made by LSM producers.  This means one thing
LSM producers are putting there framework before the good of everyone.
  This just cannot keep on going its a path to more and more forks and
more confusion.

Is it Linus getting in way I think not.   Because upgrades are making
it.  Slowly making it but they are making it.   Is it LSM makers
trying to alter the single security framework to there model.  I am
almost perfectly sure that is the main problem.  Next problem is LSM
vs LSM one up man ship ie mine is better than yours or Mine can do all
yours can with 12 times more complex config file.  Not taken a
complete look to see if both sides have advantages.

Part the problem is if you upgrade the single security framework
enough selinux apparmor... most of the LSM will become side shows of
very little importance to security more a s backup to the main
security.  Focus may move back to the old unix locations.  PAM for
creating users and assigning rights and application controlled
security.

Key thing to put  features into the existing single security framework
is flexibility and application control.  Application controlled
security can always beat selinux apparmor and every other LSM I have
ever seen.  The most advanced design of security just happens to the
one you cannot remove.   It also happens to be the most neglected.
The weaknesses that exist in the single security framework is lack of
advancement and repair.

What I class as features is like a fix to a small part.  Ie SUID too
powerful fine grained controls required.
Disk access control methods for file systems without using the
permission system. << Apparmor and relegated path base back end
engine. This also partly allows applications to protect there own
internal users from each other without needing to create system wide
users.  Basically in time internal application users should be equally
protected from each other as system wide users.  This enhancement goes
far past the common day scope of apparmor.  This is the advantage of
taking it out of LSM or at least looking to.  You may see where it can
be make 1000 times more useful as feature than a LSM and provide many
more times system protection even in ways a LSM never could.  Yes
altered apparmor could be really sell able as a core feature.

There are a lot of parts in LSMs that can be broken down into single
feature enhancements.  Major difference is how these features are
controlled.   Applications must be able to directly lower access on a
thread by thread base.  Never raise it.  These features are also
provided to all users on the system to control always even if they
cannot use them due to lack of rights.

Explain to me how its not bitrot leaving the key security framework
without features and then dividing up those features between different
incompatible parts.  This is the basic define of bitrot because you
are making a bigger and bigger mess.

Peter Dolding

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

[Casey Schaufler]

--- Peter Dolding <oiaohm@gmail.com> wrote:


> Improvements to the single security framework are getting over looked.

Please post proposed patches.

>   I would have personally though selinux would have done Posix file
> capabilities as a general service to all.

Posix capabilities predate SELinux. SELinux is not interested in
Posix capabilities. 

> But no IBM had to do it.

Err, no. It was done by Andrew Morgan back in the dark ages.
Why on earth do you think IBM did it?

> ...

OK, you have all the answers. Show us some code or STFU.


Casey Schaufler
casey@schaufler-ca.com

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

[Peter Dolding]

On 11/1/07, Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> --- Peter Dolding <oiaohm@gmail.com> wrote:
>
>
> > Improvements to the single security framework are getting over looked.
>
> Please post proposed patches.
>
> >   I would have personally though selinux would have done Posix file
> > capabilities as a general service to all.
>
> Posix capabilities predate SELinux. SELinux is not interested in
> Posix capabilities.
>
> > But no IBM had to do it.
>
> Err, no. It was done by Andrew Morgan back in the dark ages.
> Why on earth do you think IBM did it?


Posix file capabilities the option to replace SUID bit with something
more security safe only handing out segments of root power instead of
the complete box and dice like SUID.  Even different on a user by user
base.

Posix capabilites is what Posix file capabilities is based on.  Yes I
know the words appear close.  The word file is important.  Please read
Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

IBM coders worked and got it into the main line really recently to
provide at least some way to avoid fault of SUID of course it could
still be made better.  I would have though being a important problem
that other LSM guys would have done it first.  So door to add new
features to kernel is open past any question.  Of course the features
have to be for everyones good.

Andrew Morgan Posix capabilities is something far older its been there
for ages pre selinux the correct fix to SUID for everyone has always
been there by extending Andrew Morgan's work.  So I will ask again why
did IBM have to do Posix file capabilities instead of Selinux.
Selinux has had 7+ years to do it.

Thank you for proving my point past question Casey Schaufler.  You
don't have a single clue of the alterations happing to the main
security model so there is every chance you will overlap with it.

Please get you tech right.  How many other holes are sitting open
because you patch them at LSM level and don't look down into default
security system to see if it should be fixed there.

>
> OK, you have all the answers. Show us some code or STFU.

That is no explanation to why the default security frame work is being
neglected.  I don't have all the answers.  It does not take a person
that high so see that LSM is a screwup leading to people being out of
touch with the main security model and its neglect.  It should not be
requiring outside parties to fix things that in the main security
model.  Only way that can be happening is if LSM is dysfunctional.  7+
year fault at min is not what you can call someone fixing a new fault.
 Now how are we going to fix the mess of LSM's to work correctly for
the good of linux.

One way is appoint one hard minded maintainer that is above my rights.

This is above me doing code.   No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section.  Strict
policies on fixing the main security model will be required.

Peter Dolding

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

[Jan Engelhardt]

On Nov 1 2007 12:51, Peter Dolding wrote:
>
>This is above me doing code.   No matter how many fixes I do to the
>core that will not fix dysfunction in the LSM section.  Strict
>policies on fixing the main security model will be required.

If there is no one wanting to fix the existing code, then the
perceived problem is not a problem.

Or to put it another way:
"You talk the talk, but do you also walk the walk?"

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

[David Newall]

Jan Engelhardt wrote:
> On Nov 1 2007 12:51, Peter Dolding wrote:
>   
>> This is above me doing code.   No matter how many fixes I do to the
>> core that will not fix dysfunction in the LSM section.  Strict
>> policies on fixing the main security model will be required.
>>     
>
> If there is no one wanting to fix the existing code, then the
> perceived problem is not a problem.

What an absurd claim.

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

[Peter Dolding]

On 11/1/07, David Newall <david@davidnewall.com> wrote:
> Jan Engelhardt wrote:
> > On Nov 1 2007 12:51, Peter Dolding wrote:
> >
> >> This is above me doing code.   No matter how many fixes I do to the
> >> core that will not fix dysfunction in the LSM section.  Strict
> >> policies on fixing the main security model will be required.
> >>
> >
> > If there is no one wanting to fix the existing code, then the
> > perceived problem is not a problem.
>
> What an absurd claim.
>
I agree.  If they can provide a reason.  A correct reason why its not
being fixed then the perceived problem does not exist.  Until then it
common human flaw Tunnel vision.  People normally don't look at the
big picture.

Common fake reason is that Linus does not approve.   History of
patches completely disagrees with that.  Parts Linus has blocked have
been out of alignment with the build into kernel security model.  Yet
other parts that were in alignment with the model have got in during
the same time.  Perfect example of dysfunction making up a lie because
things will not go into kernel exactly how they want.

LSM is nothing more than a testing and model zone.   A place were
important features should not be.  It was put there because model
designs could not get along.   Did that mean that LSM was were the
features were intended to stay.  No the goal should be simple to get
as many good features into the main line as possible while staying in
alignment with the main kernels model.  I don't know where the wrong
idea that the main line did not have a security model came from
either.  Something does not have to be a LSM to be a security model.

XEN, KVM and lguest are not a suitable workaround to problem.  Its
more of LSM developers trying to say its not needed so don't have to
work with each other.  I am not always using x86 machines so at times
not one of those solutions fit.

Containers in Linux kernel get to be processor neutral in features.
So it will not matter what the processor chip it will work.  So the
correct solution to running many LSM somehow has to be done with
Containers.

Note calling me a know it all is not an answer either.   Either they
can put have a good explanation for there failing or the need asses
kicked.  Heck if I am wrong I need ass kick and perfectly prepared to
accept it.  The problem is I am not a person to accept invalid answers
what they have been giving me so far.

My main base is System Administration.  Not coding please note that
System Administrators are the final clients.  If you want someone with
System Administration back ground to take up the leadership of LSM and
bash it into a System Administrator friendly shape I am more than
prepared to do so.  I can bet a System Administrator in charge who is
looking from flexibility's and security point of view is going to get
noses really badly out of joint.  The flexibility bit is currently
missing.   Its not always possible to reboot a server just because the
security framework is not up to the job or client wants you to use a
tighter model.

Yes so people trying to lie to me is something I have very little
tolerance with.  Paperwork like PHD don't scare me off.  I have had to
repair networks destroyed by people with PHD with masters in computer
programming because they run a BIOS destroying virus from a outside
source.  So lets just say my trust has to be earned and using
incorrect facts don't get trust from me.

There is a bigger one than just Containers.  Its called linux on
desktop.   Some how security models will have to tolerate being
controlled from a central server.  Preferred 1 model so any number of
Linux Distros can be used in a network.  Just like different versions
of windows can now.  So somehow we have to get to one master model.
Even if the other models are just like feature tweaks.  Application
controlled allows pam and ldap into play.

Selinux jamed in does not really suit what is needed.  The world of
Linux is changing the LSM need to get there but into gear and catch
up.

Peter Dolding

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

[Andrew Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Dolding wrote:
> On 11/1/07, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> --- Peter Dolding <oiaohm@gmail.com> wrote:
>> Posix capabilities predate SELinux. SELinux is not interested in
>> Posix capabilities.
>>
>>> But no IBM had to do it.
>> Err, no. It was done by Andrew Morgan back in the dark ages.
>> Why on earth do you think IBM did it?
> 
> Posix file capabilities the option to replace SUID bit with something
> more security safe only handing out segments of root power instead of
> the complete box and dice like SUID.  Even different on a user by user
> base.
> 
> Posix capabilites is what Posix file capabilities is based on.  Yes I
> know the words appear close.  The word file is important.  Please read
> Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html

For the record, I think you are both right. I took a stab at it back
when Casey and I first met:

ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README

all that stuff worked fine it was just a bit ahead of its time...

- From memory, at that point in time "extended attributes" were an
external patch, and having some trouble getting merged. My sense was
that EA was a pre-requisite and I was happy to wait for that support to
become integrated before pushing my file capability support.

In the midst of all this LSM emerged as a reaction to Linus' clear
unhappiness about all extensions security. I didn't have the time to
participate in the LSM, and my work sat in the form of these patches.

SELinux at that time existed as a separate infrastructure, and evidently
did have the time to embrace LSM.

> IBM coders worked and got it into the main line really recently to
> provide at least some way to avoid fault of SUID of course it could

[...]

So, yes, IBM (Serge) deserve full credit for starting over, and getting
it merged...

Cheers

Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHLr6EQheEq9QabfIRAsOrAJ9XzTL0Lqm5jaxwO6UoPB9Pwh3SzQCfVWFd
cPyjsGp/s6D6HuBE6M4NJH0=
=G/ah
-----END PGP SIGNATURE-----

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

[Serge E. Hallyn]

Quoting Andrew Morgan (morgan@kernel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Peter Dolding wrote:
> > On 11/1/07, Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> --- Peter Dolding <oiaohm@gmail.com> wrote:
> >> Posix capabilities predate SELinux. SELinux is not interested in
> >> Posix capabilities.
> >>
> >>> But no IBM had to do it.
> >> Err, no. It was done by Andrew Morgan back in the dark ages.
> >> Why on earth do you think IBM did it?
> > 
> > Posix file capabilities the option to replace SUID bit with something
> > more security safe only handing out segments of root power instead of
> > the complete box and dice like SUID.  Even different on a user by user
> > base.
> > 
> > Posix capabilites is what Posix file capabilities is based on.  Yes I
> > know the words appear close.  The word file is important.  Please read
> > Website.  http://www.ibm.com/developerworks/linux/library/l-posixcap.html
> 
> For the record, I think you are both right. I took a stab at it back
> when Casey and I first met:
> 
> ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/old/kernel-2.4-fcap/README
> 
> all that stuff worked fine it was just a bit ahead of its time...
> 
> - From memory, at that point in time "extended attributes" were an
> external patch, and having some trouble getting merged. My sense was
> that EA was a pre-requisite and I was happy to wait for that support to
> become integrated before pushing my file capability support.
> 
> In the midst of all this LSM emerged as a reaction to Linus' clear
> unhappiness about all extensions security. I didn't have the time to
> participate in the LSM, and my work sat in the form of these patches.
> 
> SELinux at that time existed as a separate infrastructure, and evidently
> did have the time to embrace LSM.
> 
> > IBM coders worked and got it into the main line really recently to
> > provide at least some way to avoid fault of SUID of course it could
> 
> [...]
> 
> So, yes, IBM (Serge) deserve full credit for starting over, and getting
> it merged...

There are still pieces to line up.  Note that Andrew Morgan is working
on a patch to make the securebits per-process to make capabilities
more useful as well as a 64-bit capability patch.  And the support in
tree to date would be riddled with gotchas without Andrew Morgan's,
Stephen Smalley's, and Casey Schaufler's input.

-serge

(But hey, thanks :)

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

[Casey Schaufler]

--- Rob Meijer <capibara@xs4all.nl> wrote:


> >     * The proposal only allows a single implementation of each formal
> >       model. In theory, theory is just like practice, but in practice it
> >       is not. SMACK and SELinux follow substantially similar formal
> >       models (not exactly the same) so should we exclude one and keep
> >       the other? No, of course not, because in practice they are very
> >       different.
> 
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.

The Smack development has benefited greatly from comments, suggestions,
and bug reports from members of the SELinux community. Further, I have
had no trouble whatever sharing the netlabel component with SELinux.
Audit is another matter as it requires some work to get the SELinux
dependencies out, but everyone's been receptive to proposals there.
Why on earth would I want some 'model maintainer' passing judgements
on my work in progress? The only thing I can imagine a 'model
maintainer' doing is obstructing innovation. Unless it was me, of
course. Linus is right, you know.


Casey Schaufler
casey@schaufler-ca.com