Hello,

Thanks for your response, Steve. It sounds very logical to me. Anyway,
I've cc'ed spender (grsec developper). It would be interesting if he
could add his comments here in this ticket since he's perhaps the more
capable person to answer grsec issues. Perhaps he can refute some of
your arguments :)

If not, the workaround could be ok for me and you could close this
ticket but first let's wait for Brad's answer, please. Apart from this,
do you have a list of libraries/packages that should be fixed? Because
somebody would have to file tickets for those packages, I guess. I'd do
by myself but I'm not a grsec nor Debian expert :-(

Regards,
-Roman


Steve Langasek wrote:
> On Mon, Sep 12, 2005 at 06:18:22PM +0200, Roman Medina wrote:
> 
>>Package: kernel-patch-grsecurity2
>>Severity: critical
>>Justification: breaks unrelated software
> 
> 
>>Grsec patch is incompatible with glibc post-v.2.3.2.
> 
> 
> I don't think that's actually true.  From what I can tell, what happens
> is that glibc now enforces requests for an executable stack, and bails
> immediately at startup rather than risking a failure sometime later when
> one or more libraries has requested an executable stack.
> 
> 
>>http://lists.debian.org/debian-user/2005/08/msg00747.html
> 
> 
> This post describes a correct workaround, pending resolution of the bugs 
> in libgcrypt, libcrypt, etc.
> 
> 
>>http://forums.grsecurity.net/viewtopic.php?t=1152
> 
> 
> This thread doesn't seem to include posts from anyone who actually has a
> clue about the nature of the bug, or who has tried to file bug reports
> with Debian about it (other than the original poster).  It does,
> however, include posts from at least one known troll.
> 
> To the best of my knowledge, there are only a handful of significant
> libraries in Debian which have this bug; they should be fixed, but there
> is a known workaround for those applications which require an executable
> stack.
> 
> This is not a glibc bug; there is no bug in *reporting* the kernel error
> when a library's request for an executable stack cannot be honored, and
> it is not glibc's job to decide which executable stack requests are
> legitimate and which are not.
> 
> It is not a kernel-patch-grsecurity2 bug; grsec is working as
> advertised, and requires you to manually enable executable stack for any
> applications you wish to grant it to.
> 
> Unless you can show that the workaround for some reason doesn't work for
> you, I think this bug should be closed.
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to