Re: [RFC] [PATCH] Replace security fields with hashtable

From: Chris Wright (chrisw@private)
Date: Wed Oct 27 2004 - 10:46:36 PDT

* Stephen Smalley (sds@private) wrote:
> On Tue, 2004-10-26 at 18:04, Serge E. Hallyn wrote:
> > Attached is a patch which removes all lsm security annotations on
> > kernel objects and replaces them with a hash table.  An LSM can store
> > and retrieve information using functions exported from
> > security/security.c.
> > 
> > These are:
> > 	int security_set_value(void *ptr, int lsm_id, void *data,
> > 				int gfp_flags);
> > 	void *security_get_value(void *ptr, int lsm_id)
> > 	void *security_del_value(void *ptr, int lsm_id)
> > 
> > This naturally solves the lsm stacking problem.  It has the added
> > benefit of saving memory (and presumably time) on a system with LSM
> > compiled out.
> This would represent a step backwards for LSM, not an improvement. 
> Getting security fields in the kernel objects was an important
> accomplishment for LSM as part of making the security infrastructure
> integral to the kernel.  Removing it will clearly always cost us for the
> (presently common) case of a single LSM, and you do not need to remove
> it to add support for stacking LSMs.  I would also be concerned about
> maintainability; the more you hide the security fields from the core
> kernel, the less likely they will get considered as changes are made by
> the core kernel developers.

I'm inclined to agree, and I know Serge has expressed similar concern.

> > I am attaching the following patches (against 2.6.9):
> > 	lsm-hash.patch: implements the hash table described above,
> > 		and removes the kernel object ->security fields.
> > 	stacker.patch: adds the stacker module
> > 	tasklookup.patch: adds the necessary tasklookup LSM hookd
> > 		for testing bsdjail.
> > 	bsdjail-full.patch: adds a bsdjail module rewritten to use
> > 		this hash table
> > 
> > On request, I can also send out the dte and digsig versions which I
> > stacked on top of bsdjail in order to test this patch.
> Rewriting SELinux to use whatever approach you devise would be a better
> test, as it will exercise your methods from every hook and likely give
> you a better sense as to both the correctness and performance overhead
> of your approach.
> Plain spin_locks are not safe here, as your methods can be called from
> hard irq or soft irq from certain hooks, and this will happen with
> SELinux.  Locking overhead is going to kill you here.

Good point.  Also, on a SMP machine with a reasonable number of cpus.

Linux Security Modules

This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 10:46:59 PDT