On Fri, 2003-11-28 at 00:59, Peter Busser wrote: > On Fri, Nov 28, 2003 at 12:34:54AM +1100, Russell Coker wrote: > > On Thu, 27 Nov 2003 23:06, Peter Busser <firstname.lastname@example.org> wrote: > > > Adamantix works together with Gentoo hardened. I really appreciate this > > > cooperation. This proves that it is possible to work together. But only as > > > long as it is on a basis of equality and provides mutual benefit. > > > > You said yourself that it would be beneficial for you to have PaX in the > > default Debian kernel source. That seems to indicate a possibility for > > mutual benefit. > > Yes. But I didn't get the impression so far that there are any Debian people > who view it like a benefit. I am still hopeful that I will be proven wrong > about this though. I would use it for sure... I daresay there are plenty of companies out there that would be interested too. I'm slowly pooling ideas to assemble for a debian-enterprise sub-project proposal, and security goals is clearly one area we need to clearly define. I can see PAX fitting into this very well. I have no doubt you will have users, in fact, plenty of users. > > > Maintaining a kernel patch package is only beneficial for Debian, not for > > > Adamantix. > > That is not what you say above. > > That is consistent with what I said above, from the Adamantix point of view. > Because there is no need to have a seperate PaX patch in Adamantix. I think > that process integrity is basic functionality of any operating system that > claims to care about security. That is why it is not optional in the standard > Adamantix kernels. If you don't like it, you have to recompile the kernel > yourself and disable it in the configuration. Some call it secure by default. > > In other words, there is no need for a seperate patch package in Adamantix. > If I were to create and maintain such a package, it would be purely for the > benefit of Debian. As I understand it, having a separate patch package is simply a procedural issue within Debian - unless you can convince the current kernel packager to include your desired (or our desired, when debian-enterprise decides PAX is a required goal) patch into the kernel immediately. The point is, when a patch (Debian packaged) is firstly made available, a bunch of people can go test it, report bugs if there are any, submit patches (eg. for other packages that might need changes to work with it), and if it is eventually "popular enough", it might even get into the kernel proper. Debian values, specifically as per its constituion, its users. Secure by default is a great goal, and one that we may get ever closer to, yet there are other goals for users, like stability, not breaking current installs with upgrades, etc. Debian is large, which may make things occur slower than you would personally like, yet we have Ways to Make Things Work (TM) - like sub projects, kernel patch packages, etc. Some of our users (eg. one of my boxes - the one dedicated to my band) have real-time scheduling and latency as highest priority. It is not even connected to the net, and thus security is a non-issue. And it would require more effort *for me and the band as Debian-multimedia users* to have to back out security patches that lowered our real-time audio performance. Of course, now that the debian-multimedie sub project is underway for a few months, if the issue arose (and it's been discussed) we might package a custom kernel just for us m.media junkies anyway. > > > I don't think that is the kind of cooperation the Adamantix > > > project is looking for. You have to come up with something better than that > > > if you are serious about cooperation in security issues. The choice is > > > yours. > > > > If you want to cooperate with Debian developers then you have to find some > > area of mutual interest. > > I think that I have already identified one area of mutual interest from the > Adamantix point of view (see above). I think that mutual means that the effort > comes from both sides. Therefore I am interested in hearing from you what this > effort from Debian's side is going to be. debian-enterprise sub project is (assuming, at the very least, that I don't personally get hit by a bus) at least one example where (I believe) PAX would be of high interest... > But I suspect that the answer is going to be something like: Put a patch > package in Debian and then, if you are really really really lucky, you might > see some minimal reward for your effort. That is again expecting Adamantix to > do work for Debian with nothing in return. Such a circular argument leads to > nothing. If nothing is what you want, this is the guaranteed way to get it. The Debian Way (TM) works for over one thousand three hundred developers, and I'm guessing in the order of millions of users. This is expanding all the time. I would not personally characterise gaining even a fraction of the Debian userbase (eg. as might be defined in the future by debian-enterprise subproject) as "minimal" reward. In fact, it is that there is so much good about Debian that it has grown so big. And we are steadily growing ways to grow with the growth in users (eg. subprojects). Another current example is the Knoppix/ Debix integration/ installer/ live CD discussion going on right now. I am looking forward to the day where we have a good chunk of the live CD "user" market, where Debian is basically _the_ distro to use (easy, comprehensive, support forums, etc) for such custom CD builds... and I would be very surprised if there weren't many applications for a "highly secure" live CD recipie... hmm, so many possibilities. Have to stop drooling now. cheers zenaan -- Phone: +61 (0)412 166 990 Homepage: http://homepages.ihug.com.au/~zenaan/ PGP Key: http://homepages.ihug.com.au/~zenaan/zen.asc Please respect this email's confidentiality as sensibly warranted.
Description: This is a digitally signed message part