View Poll Results: Did you previously know about PaX and SSP?
- 9. You may not vote on this poll
I knew about PaX
I knew about ProPolice/SSP
I knew about both
I use PaX
I use SSP
I use both
Results 1 to 4 of 4
I'd like to discuss two proactive security projects, PaX and ProPolice. What these do is mitigate future security exploits down to DoS attacks, which may be appropriate for many situations; ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 08-09-2004 #1
- Join Date
- Aug 2004
Anyone Mention Pax And Ssp Here? :) Proactive security :)
I'd like to discuss two proactive security projects, PaX and ProPolice. What these do is mitigate future security exploits down to DoS attacks, which may be appropriate for many situations; if an intrusion isn't acceptable, but the crashing of Apache/sshd/ircd/whatever is attacked is, these two technologies are perfect.
Because of their nature, i believe these are useful in 100% of home use scenarios; neither of these, when managed by the distrbutuion, pose any extra security barriers (Passwords, access restrictions, etc) to the user or system administrator, yet they both will easily deflect worms of the nature of Sasser and MSBlast that are targetted towards vulnerabilities in Linux systems. These will NOT deflect worms in the nature of ILoveYou, which are targetted at bad-by-design normal functions of software; the problem of such attacks is of the same nature of "user B saw user A's password" attacks, and cannot be detected by any method.
PaX you'll know as that weird thing that you probably didn't realize wasn't PART of grsecurity, just PACKAGED with it
SSP/ProPolice is another good one, does good things.
The below articles should kick this discussion off well.
I'm the major contributor of these two, although lots of help came from others' input. Big thanks to the PaX developer for technical explainations of PaX.
Now that you're introduced to the topic, anyone have anything they'd like to discuss about these?
BTW, I put the poll there because I'm curious about how many people know about and/or use these already You people are a good survey group. And yes, I cast my own first vote; I'm part of the survey population, although that's bad statistics.
- 08-09-2004 #2
- 08-10-2004 #3
- Join Date
- Aug 2004
Careful with that
I'm exceedingly glad you said TEST servers.
You might note that some things break on 32-bit x86. There's good stuff for this on Gentoo and Debian; on Gentoo I really suggest you use the updated ones at http://bugs.gentoo.org/show_bug.cgi?id=40665 to get away from the fully exploitable Mozilla family (a la http://news.com.com/Image+flaw+pierc...3-5298999.html ). For the debian hack-job (something I'm using to try and convince the devs to use this in the base system), http://pax.wooyd.org/ is some space lent to me by one of the devs; don't slashdot it, he'll pull it. Other than that, you'll have to poke around with paxctl/chpax and execstack yourself.
I'm using an AMD64 now, and I've noticed no breakage by PaX. I'll note that AMD64 has proper usage of the NX bit by default; but that the policies supplied with PaX are more secure. You also get the ASLR out of PaX. You still want to keep a non-pax kernel around in case your stuff suddenly ceases to function.
Remember, unless you have PT_PAX_FLAGS in yoru binaries (requires a patched binutils), you'll need to use chpax, not paxctl. In particular, java will need to be flagged with chpax probably everywhere.
ONE MAJOR THING YOU NEED TO KNOW, older glibc (not old old, but old as recent Debian Sid) will die with PAGEEXEC enabled on 32 bit, because that force-disables the vsyscall page. You'll want to use SEGMEXEC only on 32 bit, or else init will get killed. There's a backported patch of the fix for this from upstream glibc in Sid now; and current Gentoo Linux seems to have working glibc as well.
If you have any problems, just leave a reply on this thread.
- 08-18-2004 #4
- Join Date
- Aug 2004
By the way. . .
I've done some PIC/PIE tests. Position independent code makes up most of the system; all libraries are posistion independent. Executables are all fixed position. Fixed position code is slightly faster and more compact, but can't be easily relocated. Of course, for PaX to reliably randomize the base of the executable, it should be position independent. If it's not, relocation overhead skyrockets, and you may get false PaX kills (killing a program for doing nothing wrong).
Tests done on amd64 and x86 are at http://usrbac.sourceforge.net/misc/pie.txt for now. These demonstrate that the overhead is not significant.
As a caveat, remember that the extra overhead from PIE (Position Independent Executable) is a fraction of the actual PIC overhead; most of your system is already PIC, so it's like slowing down n% of your execution by x%, which makes an effective ((n*x)/100)% slowdown.
Notice that on x86 with framepointers omitted, fixed position code gets about a 5% speedup. This speedup is lost for position independent code. In relation to normal fixed position code, the slowdown is about 0.99%; in relation to -fomit-frame-pointer fixed position code, the slowdown is 5.81% (0.99% plus loss of a potential optimization).
The AMD64 tests use -O3, which omits framepointers. The difference is about 0.028%. Without framepointer omission, my measurements showed that PIC is faster than fixed position code; this indicates that there is no significant penalty on amd64 for position independent code. These tests did not determine if -fomit-frame-pointer affects PIC, or if it just has no significant impact.