Mainline GRSec + PAX

Discuss and suggest new grsecurity features

Mainline GRSec + PAX

Postby zakalwe » Thu May 17, 2007 2:40 pm

Ok, im sure this must have come up countless times before, but I'd like to get a better understanding of the situation.

I read these two old gems to try understand the historical/political/technical objections to PAX and the like.

http://marc.info/?l=linux-kernel&m=90255305001311&w=2

and

http://kerneltrap.org/node/4590


As far as I can tell, the only objection to PAX now is the sheer awesomeness of it, in scope and complexity. It's also clear that having a drip feed of a poor mans PAX into mainline doesn't make any sense. Now seems to be the time to lock heads with somebody constructively before things diverge too much.

It looks like this problem is because of Linus' misjudgment in 98. Linux security has developed as a varying collection of 'fixes' maintained out of tree ever since. That had some acceptance back then, when most people could see no light at the end of the security tunnel. PAX is (indisputably?) the most complete fix (with a few things still to be done). Is the only thing people hold against it is the amount of code it touches?

In your opinion would the Linux kernel be more difficult to maintain and code for if PAX was in it by default. You must be the best one to judge, since you have maintained it out tree for so long.

There is also some debate as to what level you have to fix security before it is adequate. Well, for me, it would be to the best you could without a drastic performance and system maintainability hit. I understand that there is no point fixing one way to breach the system if it's just as easy to do it another way. You have to fix everything at every level to a point at which security becomes highly probable, if not deterministic.

With PAX and grsec the performance hit is negligible on my machines. (I guess some 'features' enabled might hurt some workloads more than others). Are there any comprehensive benchmarks in this area?

For admin maintainability GRSecurity+PAX almost covers all use cases. It really could be the ultimate solution.

1) Turn everything GRSEC + PAX related off in the kernel.

2) A single, very simple policy that would improve basic security somewhat. Easy for any distro to include.

3) A tighter default policy, that admins would then manually add to using the per subject learning feature.

4) Do the full system learning, hand tweak it after, and add to it as necessary with the per subject learning.


I think there is an unfilled middle ground between SELinux and grsec in terms of policy granularity, maintainability and security. I think this is what most people would want. If the grsec RBAC was more modular with regards to policies so that a distro could maintain a set on a per package basis, a use case basis, and all points in between who could argue with it then?

Am I talking shit or could that be done?

Do you actually want all or some of PAX/grsec to be mainlined anyway? Can you maintain it out of tree indefinitely?
zakalwe
 
Posts: 22
Joined: Mon Jul 10, 2006 9:40 am

Return to grsecurity development

cron