Re: exec-shield (maybe ITP kernel-patch-exec-shield)
Hi!
> > 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.
Ok, that is nice to hear. Currently I'm way to busy with RSBAC development for
Adamantix. When that is more or less ready, I think I have time to create a
kernel patch package if you (or someone else) can do the Debian paperwork.
> > 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.
I would think that the recent break-in should be convincing enough that you
can't simply ignore security or downplay the importance. Of all products
available today, PaX is by far the best. It is also better than OpenBSD's W^X.
That it breaks stuff is mostly FUD.
> 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.
Sounds reasonable.
> 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.
That is why there are different distributions, so that people have a choice.
> 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.
There is a live CD-ROM that does RSBAC (not Adamantix though). And there is
also an Adamantix live CD-ROM. It does not do RSBAC at the moment, because
support for RSBAC in Adamantix is still under development. But it will do
RSBAC and graphics in the future. RSBAC should also be of interest for you, if
you target enterprises. Feel free to contact me when you start to work on your
enterprise project.
Groetjes,
Peter Busser
--
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world
http://www.adamantix.org/
Reply to: