LSM -- Couldn't you do a similar yet different alternative?

Discuss and suggest new grsecurity features

LSM -- Couldn't you do a similar yet different alternative?

Postby bluefoxicy » Wed Nov 26, 2003 3:12 pm

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.
bluefoxicy
 
Posts: 5
Joined: Mon Nov 24, 2003 10:02 pm

Return to grsecurity development

cron