LSM offers hooks into the kernel to evade the underlying, simple security system correct? Couldn't such hooks be implimented in a less exposing manner?
I'm thinking staticly compiled in security options, not modular, meaning NO external extensions could be added without a recompile. The idea would be that the configuration script would count how many security systems there were (LSM allows for chaining, right? Poorly, I hear, but it does from what I've heard . . .) and note that in the kernel, then allocate an array of function pointers for each, and automatically handle calls to the security code, deny/grant/override, etc. All symbols could be hidden, as all the work would be internal and the function pointers would be hardcoded. You'd just have to protect /dev/mem and /dev/kmem.
Not saying that you're going to topple over the LKML with an idea like that, or that it's better than just cramming GRSecurity in as is, but hell it's a starting point to compromise with. The theoretical ideal is to remove all attatchment points into the kernel from the view of any external attack, right? Just trying to get a handhold on what's going on here.