Messages in this thread | | | Date | Wed, 10 Nov 2004 13:32:29 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] [PATCH] [2/6] LSM Stacking: Add stacker LSM |
| |
> Unless I've missed it, you never check num_stacked_modules against > CONFIG_NUM_LSMS. If somebody loads too many modules, they risk > overflowing all of those void * security arrays you've added to so many > kernel data structures, and thus corrupting those structures. That, in > technical terms, would be a bummer. > > In stacker_unregister(), you do: > > > + num_stacked_modules--; > > What happens if you unload anything other than the last module, then > load something else? When you return num_stacked_modules-1 to the new > module, you'll point it to a slot in those security arrays which is > already used by another module. The result seems unlikely to improve > security. > > Unless I'm simply confused? It's happened before...
No, you're not. While I sent out all the patches to make the first patch useful, the stacker patch was the same one I've been using with several other approaches to sharing the void * security arrays. If the first patch turned out to be acceptable, the stacker patch would have been tweaked quite a bit. As Chris Wright pointed out, the list of stacked modules would no longer need to be a linked list, and so the semaphore guarding that list could be dropped. And of course your points are valid.
I am working on a new implementation, which I will send first to the lsm list and lsm and selinux maintainers. Lmbench numbers from this morning show that with this approach, a kernel with selinux + capabilities shows no performance degradation.
thanks, -serge - 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/
| |