Re: [developers-l] Re: [debian-devel] Re: security enhanced debian branch?
Hi! On Thu, Dec 18, 2003 at 06:39:28PM +, Magos?nyi ?rp?d wrote: A levelez?m azt hiszi, hogy Matt Zimmerman a k?vetkez?eket ?rta: On Thu, Dec 18, 2003 at 09:07:02AM -0400, Ben Armstrong wrote: Second, any such effort shouldn't be a branch, but should be mainstreamed in Debian proper. Please see http://wiki.debian.net/CustomDebian for a possible approach for this sort of project. For cases where the added functionality is provided by additional packages, this is easy. However, some of the things which are being experimented with include compiler patches to produce binaries which make certain types of exploits more difficult, and that kind of thing is not easy to merge into Debian proper. I think this kind of stuff could be handled in new architectures. For example the Adamantix project could be merged back by creating an architecture i386-adamantix for the stack protected stuff, and the other parts being a CDD by the terminology of the above link. Such solutions have been discussed since Trusted Debian 1.0 was released, which was end of April this year. But discussions do not get the work done. (I do not know enough about the history of the project to tell if its developers would consider merging back a good idea or an organisational impossibility. But the main point is not about that, or even that project in particular.) Merging is a bad idea. Adamantix and Debian are different projects with different goals. It is IMHO a good idea to put back stuff from Adamantix in Debian. Currently I am fully occupied by development of RSBAC support in Adamantix, so I cannot do it myself. But anyone who wants to work on this stuff for Debian can join #adamantix on irc.freenode.org or send e-mail. There are always people on #adamantix who are willing to share information and answer questions (including so called stupid questions). Even if you don't know much about this stuff, we can get you up to speed and try to help when you get stuck. People who talk badly about Adamantix either do not know what they are talking about or do so deliberately. I.e. by spreading FUD, making it look like a fight between ``us'' and ``them'', as if there is nothing in common between the two projects. All in all, it seems to me that there are a few people in Debian who think that it is against their personal interest when Adamantix stuff is added to Debian, even though it is clear that it is in the interest of all Debian users to have better security. Anyone related to Adamantix that I know of has been helpful with helping others, including Debian users and developers. There is a good relationship with Gentoo hardened. And there is no reason at all why there is no such relation between Debian and Adamantix. A good start would be if some Debian developer started to write a plan for putting Adamantix stuff in Debian. Then we can discuss it and determine what needs to be done by whom. And then start working on it. Groetjes, Peter Busser
Re: Building a distribution from source?
Hello! On Sat, 6 Dec 2003 04:37, Jakob Lell [EMAIL PROTECTED] wrote: maybe Adamantix is what you are wanting to do. It is based on Debian woody Adamantix in now what we want to do, what we want to do is to improve Debian. ``We''? Who is ``we''? It is unlikely that you are one of them royal people, so I take it you meant to say: Adamantix is not what I want to do, what I want to do is to improve Debian. Fair enough. But if I were to improve Debian, I would put PaX in the default kernel source. create installation CDs yourselve. For more information about Adamantix, see http://trusteddebian.org/ That URL is obsolete. Right, it is obsolete. Please use http://www.adamantix.org/ instead. Not that it makes any difference, because you end up with the same web page in front of you. They can not use the trusted Debian name any more. ``They''? Who is ``they''? Does ``they'' include Debian developers who actively contribute to Adamantix or not? You don't make any sense here Russell, let me rephrase it again: Peter can not use the trusted Debian name any more. Oh yes I can. Martin Michlmayr and I have an agreement that I (you may read ``we'' here if you want) can use the trusteddebian.org domain for the web site and for e-mail (although not for advertising it). That is why you see a big Adamantix logo when you select www.trusteddebian.org. IMHO it was a big win for the project to be renamed from Trusted Debian to Adamantix. In fact the domain should probably be de-registered to avoid confusion. If anyone appears to be confused here, it seems to be you (again). Groetjes, Peter Busser
Re: Exec-Shield vs. PaX
Hi! this intentionally calls mprotect(PROT_EXEC) for the highest possible address one can think of. This call has no useful purpose at all. In other words, this is a specific, underhand cheat to trigger 'Vulnerable' messages for all items when running paxtest on exec-shield kernels. Bravo! If you get bad grades on school, don't work harder, blame the teacher. Other people have been asking for such a test, because there was speculation about this vulnerability in exec-shield. It is in fact a simulation of a multithreaded application. I objected to adding tests that include a multi- threaded library, because the library might interfere with the results of the test. So instead of adding a library that would perform the mprotect(), the mprotect() itself was added. Since multi-threaded applications are not that uncommon. Therefore the results are quite relevant I think. People deserve to know what the limitations the security products they use have. That is why the return to function tests have been included, to show that PaX is good but not perfect. Paxtest simply shows if people tell the truth about memory protection patches. I wrote it to see if what pageexec told me about it was true or not, so I wouldn't lie to people when I tell them Adamantix has good memory protection. There are already too many lies in the security world that there is no need for even more. And after all, if exec-shield is being included in the Debian default kernel source, then you are talking about the pride of a 1000 developers that are at stake here. That is not something you should take lightly if you ask me. :-) frankly, i've never experienced anything like this in my many years in the Linux world. You so far gave the impression of a reasonable and balanced person but this is as low as it gets. Shame on you. Do you have the detailed specification of exec-shield somewhere? That would make it easier to evaluate the completeness of the test suite. Feel free to submit tests yourself, I'll add any sensible test. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Grsec/PaX and Exec-shield
Hi! I volunteered to make a package for exec-shield because it meets the Debian criteria, I have time to do it, and it interests me. PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? In fact, anyone can do it Russell, I'm pretty sure even you can do it: apt-get install kernel-source-2.4.22 cd /usr/src tar xvfj kernel-source-2.4.22 cd kernel-source-2.4.22 wget http://pageexec.virtualave.net/pax-linux-2.4.22-200310051430.patch patch -p1 pax-linux-2.4.22-200310051430.patch And now you can make menuconfig etc. Now, that wasn't too difficult, right? I worry about the security of my own machines, and that of people I know. Exec-shield offers some benefits and is something I can use now. PaX will not work with the Debian kernel and no-one has volunteered to make it work. Unless someone (maybe you) volunteers to get PaX working with the Debian kernel then it won't be an option for most people. So you tried to apply PaX to the Debian kernel and failed? Can you explain what exactly you did, which kernel version you used, which PaX patch and how you applied it? I really don't understand why an experienced kernel patcher like you can have problems with a nobrainer patch. I do it all the time for Adamantix kernels (which are based on the Debian kernel source packages) and it goes in without a hitch everytime. I wish other patches were as easy to apply. And it works. The Adamantix kernel is used on mission critical production systems. I have installed the PaX kernel on a Debian Sarge system and it worked. Any Adamantix user will tell you that PaX works. I honestly do not know what you are talking about. And if I didn't know any better, I would think you were a newbie. You can even disable some of the PaX features to lower the level of security to the exec-shield level. Another thing is that exec-shield is (AFAIK) only availabe on the i386 platform. I always thought that Debian was a multiplatform distribution. PaX is supported on Alpha, PowerPC, HPPA, Sparc, etc. (I think that AMD64 is also supported). There is simply no technical reason to chose exec-shield. However, there may of course be other reasons. Such as political reasons. Anyways, I included a patch for kernel-source-2.4.22 here. It took me 10 minutes to create it (yeah, slow computers suck). I'm sure Herbert Xu knows how to apply it. For those who don't: apt-get source kernel-source-2.4.22 cd kernel-source-2.4.22-2.4.22 bzcat kernel-source-2.4.22+pax.diff.bz2 | patch -p1 Now that can't be too hard, can it? Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ kernel-source-2.4.22+pax.diff.bz2 Description: Binary data
Re: Grsec/PaX and Exec-shield
Thomas Viehmann wrote: So, please don't start insulting and accusing people for doing good work and proposing to do even more of it. If there are technical reasons that cause you to prefer that exec-shield does not become part of Debian's standard kernel, just put them on the table, but save us your conspiracy theories. I have seen noone accusing Russel from doing good work. The problem here is not the good work, it is the things he says that can easilly be proven wrong. For those who don't know, Adamantix is a Debian based distribution aiming to create a highly secure Linux system. Most packages used in Adamantix are Debian packages, including the kernel packages. Almost all packages have been recompiled to make maximum use of the features PaX provides. Most programs run fine. Only a handful of programs have problems. PaX has been a standard part of the kernel in Adamantix for almost a year now. And it is used on mission critical production systems with SLAs. So what are the facts: - PaX works, even on Debian kernels. Adamantix proves it. - It provides more security than you get by installing the latest updates: http://groups.google.com/groups?selm=20030525190037%2470c6%40gated-at.bofh.it (Also proof that it works with Debian) - It takes less time to apply the patch to the Debian kernel than the time that is wasted on this discussion. - The functionality can be tuned to specific needs by changing the kernel configuration. That means, you can lower the security at a level comparable to exec-shield if you want to. - I have installed an Adamantix kernel on a Sarge system and the command line stuff worked (didn't test it thoroughly). If packages follow the current Debian policy, they should be mostly okay, even if the most restrictive settings are used (like in the Adamantix kernel packages). - You don't need to recompile if you don't want to. It only adds more security if you do. - PaX is available on different platforms and not only on i386. That is, Alpha, PowerPC, HPPA and others. - The design and implementation of PaX have been documented and are open to public scrutiny: http://pageexec.virtualave.net/docs/index.html This includes a description of limitations and design choices made, so you can find out what trade-offs have been made (or haven't been made). - PaX is independent from gr-security. And can be downloaded and applied to the kernel without having to download gr-security. - It is POSIX compliant. Programs that break are those who try to go beyond the limits of POSIX. Most of them can be fixed. And those that cannot be fixed (like the Java JDK, which is available as binary only) can be made to run without much hassle. The package maintainer can take care of this, it is as complicated as stripping binaries. We're talking about a handful of programs here anyway. - It is possible to have a fully functional distribution running on PaX. The OpenBSD project proves that, it has features similar to PaX in the kernel, and you can still run all the goodies. - Running paxtest shows the differences between PaX and exec-shield. Everyone is invited to run paxtest to see for yourself. So far I have heard a lot of talk and a number of opinions on why PaX is bad. But no proof. I can reasonably proof any of the above. But I have seen no such proof from those who propose exec-shield so far, only opinions and cheap talk. Opinions are like assholes, everyone has one. It is proof that counts. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Grsec/PaX and Exec-shield
Hi! [NB: When reponsding using the web archives, please get the References and In-Reply-To: correctly. You may also consider setting MFT:] I can't post from the lists.debian.org site. On Tue, 04 Nov 2003, Peter Busser wrote: PaX would take much more time so I can't do it. You cannot do it or you don't want to do it? Russell has made it adequately clear that he doesn't have the time or the desire to deal with PaX at this time. As a volunteer, that's always his prerogative. [As a side note, if you are trying to enlist volunteers, I strongly suggest not berating other developers while doing it.[1]] Agreed, Russell is free to do what he wants. However, other Debian developers benefit from having accurate information, to base their opinions on. And so far I have seen statements on PaX that have been anything but accurate. I'm not in fact trying enlist volunteers. I try to offend as many Debian people as possible, so that they choose exec-shield. This to ensure that Adamantix will has an edge in security over Debian in the future. And it seems to be working very well so far. Besides that, I can imagine that gr-security does not work on the current Debian kernels. But really, PaX and gr-security are two completely different things. PaX is related to gr-security in the same way the Linux kernel is related to Debian. It is just a part of it, but the PaX project is independent of gr-security. In fact, anyone can do it Russell, I'm pretty sure even you can do it: Why not volunteer to make the .deb, get a sponsor and get it uploaded then? Good idea! Already did that in fact. So who do I send this new kernel-source .deb to? Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
Re: Grsec/PaX and Exec-shield
Hi! the reply below mostly a re-sent of a mail i sent to you privately - but you repeat this argument again without any apparent answer to my counter-arguments. I already suggested you to reread the PaX documentation, there are the answers to your questions. There is no need to copy/paste it here. Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Fact is: There is a difference in paxtest output between PaX and exec-shield. And it is not a difference in exec-shield's advantage. Another fact: If you don't like this difference, you can change the PaX kernel configuration to lower the level of security to the same level as exec-shield. You didn't touch the other facts in the list, because you know you don't have any proof to easily dismiss them. You would be my hero if you succeeded in improving on PaX. But in all honesty, exec-shield does not do that I'm afraid. In fact, there is simply no technical reason whatsoever for exec-shield to exist at all. None. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/
