grsecurity forums

Would it be feasible to modify the pax pageexec/segmexec protections to only apply to certain uids/gids?

Reasoning/example: On server-1 it is desirable to have protections on processes owned by root and daemon users, but the protection of the other non-priveleged users processes is not needed.

I'm hoping this would increase system performance by gaining back some of the overhead of page/seg protection wasted on silly user processes. I'm not sure if the code to check uids/gids would waste more resources than just protecting everything though.

Let me know if this sounds like a waste of time.

h4x0r wrote:Would it be feasible to modify the pax pageexec/segmexec protections to only apply to certain uids/gids?

of course it is possible. question is whether it's really worth it.

I'm hoping this would increase system performance by gaining back some of the overhead of page/seg protection wasted on silly user processes.

is there any specific performance problem you're experiencing? SEGMEXEC+RANDMMAP causes a 1-2% slowdown on a kernel compilation (i.e., that's pretty much how 'bad' it can/should become), if you see something worse, then we'll have to investigate. as for PAGEEXEC, it is no longer the default, so you should not see the associated overhead unless you explicitly enabled it on some of your apps (is that the case? and if so, why was it necessary?).

No specific problem, it just seems like my pax protected boxen have higher loads. I just assumed it was overhead from the pax protection. I of course only use segm.

If its only 1-2% overhead for the protection then its obviously not worth enabling it on a uid/gid basis. I am curious as to how you arrived at this amount though.

h4x0r wrote:No specific problem, it just seems like my pax protected boxen have higher loads. I just assumed it was overhead from the pax protection. I of course only use segm.

how much higher? can you cite some numbers please? also, which version of grsecurity are you using? around last september (grsec 1.9.7 i think) or so there was a problem with PaX and APM that would cause higher than usual loads.

If its only 1-2% overhead for the protection then its obviously not worth enabling it on a uid/gid basis. I am curious as to how you arrived at this amount though.

simple: #time make bzImage
some results on plain 2.4.20 and w/ PaX and SEGMEXEC/RANDMMAP/RANDUSTACK:

338.93user 27.32system 6:08.75elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (710866major+910168minor)pagefaults 0swaps

343.13user 27.67system 6:13.19elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (708920major+911819minor)pagefaults 0swaps

as you can see, the sums of user+system in the two cases show a 370.8/366.25 = 1.012 slowdown (on this run, it doesn't vary much), that is 1.2%. and since the SEGMEXEC/RANDMMAP overhead really shows on workloads that do lots of fork() and execve(), this impact is probably as much as it can get in the real life.