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