* 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. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Wed Oct 27 2004 - 10:46:59 PDT