Security Basics mailing list archives
Re: Linux Distribution Recomendation
From: peter () devbox adamantix org (Peter Busser)
Date: Tue, 16 Mar 2004 15:27:20 +0100
Hi!
The debian-devel discussion was mostly about Russel Coker and Ingo's claims that his patch does everything that PaX does, without breaking compatibility. That is simply not true. It provides less protection and even then still breaks compatibility. You cannot download the XFree86 source code, recompile it with ELFLoader module support and run it as is on his kernel patch. I respect the fact that people make trade-offs, OpenBSD made similar trade-offs. Basically they trade in a bit of security for a bit of compatibility. That is ok, if compatibility is more important than security.Are we talking about the same thread? http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00206.html In this one Ingo explicitly states a few times PaX is more secure than exec-shield.
Yeah, it looks like that is one of those discussions. These discussions with Red Hat employees normally have a few standard themes. One important aspect is to assert that exec-shield is almost equal to PaX, because the extra things that PaX does are not important (even though there is no proof that this is indeed the case). If people start quoting PaXtest output that proves the opposite, it is no longer possible to repeat that assertion. So the second theme starts. That is, to question my integrity and claim that PaXtest is rigged to show bad results for exec-shield. But why is PaX able to stop these simulated attacks and why is exec-shield not able to do that? (FYI, I am not involved in PaX development in any way. I wrote PaXtest in my free time and I develop Adamantix in my free time. And I have no commercial interests to defend.) When you start to talk about the differences in design between PaX and exec-shield, and that exec-shield allows applications to do things that PaX does not allow, then it is obvious that killing the messenger does not work either. If you continue to use some more torturing, then they will finally admit that yes, PaX is more powerful (note: admitting that it is more secure requires even more torture). Boring.
With my admittingly limited knowledge of the subject I interpret this to be something like the old standards compliant GCC issue where it broke apps, but only cause those apps were relying on a broken implementation. He said X was used properly on other archs but on i386 it did not. I guess cause read-only memory can be executed people used it which sounds like a design flaw to me. http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00285.html
XFree86 is ugly.
I use fedora and have heard people mention breakage of wine with exec-shield enabled but haven't looked into why so it obviously isn't 100%.
Of course it breaks. It is trying to do all kinds of nasty stuff in the process memory. The vision of the PaX author is that introducing and executing new executable code in process memory should be a privileged operation. It should not be allowed to just anybody. The problem with this whole thing is that it is damn convenient for programmers to just mess around in the process memory and then execute that mess. But it is damn convenient for attackers too.
This is the 'middle ground' stuff you were talking about, not as good as others, but better than the default. Now I'm off to actually get informed on this whole subject =)
BTW, the PaX site contains good documentation about this subject. It describes the design and the trade-offs being made. It is well worth a read. And on www.adamantix.org, you can follow a link to a Linux Magazine article I wrote. It is not a very technical article. It should provide a general overview of what PaX does and why. (I would point to exec-shield or OpenBSD design documents too, if there were any.) Groetjes, Peter Busser --------------------------------------------------------------------------- Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off any course! All of our class sizes are guaranteed to be 10 students or less to facilitate one-on-one interaction with one of our expert instructors. Attend a course taught by an expert instructor with years of in-the-field pen testing experience in our state of the art hacking lab. Master the skills of an Ethical Hacker to better assess the security of your organization. Visit us at: http://www.infosecinstitute.com/courses/ethical_hacking_training.html ----------------------------------------------------------------------------
Current thread:
- Re: Linux Distribution Recomendation, (continued)
- Re: Linux Distribution Recomendation Peter Busser (Mar 11)
- Re: Linux Distribution Recomendation Byron Sonne (Mar 09)
- Re: Linux Distribution Recomendation Markus Schabel (Mar 03)
- Re: Linux Distribution Recomendation D.E. Chadbourne (Mar 03)
- Re: Linux Distribution Recomendation Brian Whitehead (Mar 03)
- Re: Linux Distribution Recomendation Vincent (Mar 03)
- Re: Linux Distribution Recomendation Peter Busser (Mar 04)
- Re: Linux Distribution Recomendation Vincent (Mar 08)
- Re: Linux Distribution Recomendation Peter Busser (Mar 11)
- Re: Linux Distribution Recomendation Vincent (Mar 15)
- Re: Linux Distribution Recomendation Peter Busser (Mar 16)
- Re: Linux Distribution Recomendation Peter Busser (Mar 04)
- Re: Linux Distribution Recomendation Peter Busser (Mar 08)