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

From: Stephen Smalley (sds@private)
Date: Wed Oct 27 2004 - 05:46:43 PDT


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

-- 
Stephen Smalley <sds@private>
National Security Agency



This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 05:51:21 PDT