[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.069 / U:1.916 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site