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

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


On Thu, Nov 27, 2003 at 09:40:50PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 27 Nov 2003, Peter Busser wrote:
> > > 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 for one, do (especially since I have Russell's word that it would work
> quite well along with SE Linux).

It is nice to hear that Russell changed his mind after the previous dicussion.

> But I simply cannot dedicate the time it
> takes to do it right now, so I didn't step forward.  I think there are many
> in the same situation.  So, it looked like nobody was interested... why
> increase the noise level if we DO know that in Debian you either step
> forward and DO something (then fight to the teeth to get it adopted) or you
> are just wasting your time...

Neither do I have the time. But I will see what I can do after the RSBAC stuff
in Adamantix has matured a bit. I am certainly NOT going to defend it to the
teeth to get it adopted. You're free to use whatever you like. PaX is the best
and if you believe the FUD and settle for anything less, that's fine. It is not
my problem.

> Probably we would slowly (emphasis on slowly) try to get it to be a default,
> and as such, map just about everything that needs to be tagged so as not to
> get broken by PaX, submit those stuff upstream, etc.

Debian testing worked on a test system with the Adamantix kernel-image package
(which obviously includes PaX with the most restrictive settings enabled). X
breaks, but it breaks on exec-shield too.

In the X server shipped with Red Hat Taroon (the RHEL beta version), there was
a patch which reused code added by OpenBSD that silently disables memory
protection. So instead of fixing the problem at the root, you will run an X
server that is not as well protected as you might expect. As such that is not a
problem. But noone tells you about it, and that is a problem.

> Adamantix might not earn much from it.  I really don't know. What I do know
> is that it worked well for SE Linux.

Well, if Debian packages work well on PaX and Adamantix keeps using Debian
packages, there is of course a clear benefit for Adamantix. I am not really
sure if Adamantix will keep using Debian packages, because I don't think doing
that meets the requirements needed for a high level of security assurance. For
the short term, this is not a big problem, because Adamantix is not ready to
meet high levels of assurance anyway. But as someone else pointed out already,
the risk for backdoors in important packages is too big in the long run.

Peter Busser
The Adamantix Project
Taking high-security Linux out of the labs, and into the real world

Reply to: