[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exec-shield (maybe ITP kernel-patch-exec-shield)

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 <peter@adamantix.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

> > > 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.


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.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: