unmerge 321724 reassign 321724 libelfg0 0.8.5-1 unmerge 321723 reassign 321723 libgdbm3 1.8.3-2 unmerge 321721 reassign 321721 libssl0.9.7 0.9.7e-3 severity 321721 minor unmerge 321720 reassign 321720 libgcrypt11 1.2.0-11.1 severity 321720 minor thanks On Sun, Aug 07, 2005 at 11:28:41AM +0200, Jerzy Kozera wrote: > On Sun, 2005-08-07 at 01:51 -0700, Steve Langasek wrote: > > > Google suggests this has something to do with "pax", which I've never > > > heard of and have certainly never installed or enabled. > > > -- System Information: > > > Debian Release: testing/unstable > > > APT prefers stable > > > APT policy: (500, 'stable') > > > Architecture: i386 (i686) > > > Shell: /bin/sh linked to /bin/bash > > > Kernel: Linux 2.4.18-bf2.4 > > > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) > [...] > > It should be straightforward for you to fix your system by installing a > > 2.4.27 kernel from sarge and rebooting the machine, which is the supported > > upgrade path in any case. This means the bug should not be considered > > critical; I've downgraded it accordingly. > > It is still important that the glibc package be fixed, so that it does not > > permit installation on an unsupported kernel. This has been done in the > > past for select architectures, but it seems we now have a reason to bump the > > requirement across all architectures, which should give the glibc team a > > nice clean start (and a nice clean preinst) for etch. :) > This bug appears with my 2.6.x grsecurity/PaX kernel too. I'm getting > similiar error with: > $ wget > wget: error while loading shared libraries: libcrypto.so.0.9.7: cannot > enable executable stack as shared object requires: Permission denied > It goes away after turning off mprotect() protection by chpax or > downgrading libc6 back to 2.3.2-ds1-22. > You might be interested in related threads at > - debian-user: http://lists.debian.org/debian-user/2005/08/msg00747.html > - grsecurity forums: http://forums.grsecurity.net/viewtopic.php?t=1152 > Will it be fixed so that libc will work with grsecurity/PaX? Ok, after talking with Bastian Blank on IRC, it looks fairly implausible that the version information provided in the original reports was at all correct. For one thing, the version of libacl1 that bug #321717 was reported against was a binNMU version of the package which I uploaded to fix exactly this issue in bug #301250! So, even though running etch/sid against a woody kernel is indeed not supported, that doesn't seem the issue here. Instead, Joe, it looks like you *are* running a kernel on this machine that has grsec enabled, even if you don't know how it got there. It would be helpful to have more complete information from the actual system in question to confirm this, though. I can confirm that the binaries of libacl1 and libelfg0 that shipped in sarge were built with an old compiler that did not properly set PT_GNU_STACK. The libacl1 bug was fixed in the binNMU mentioned. The bug in libelfg0 has not been fixed; I've unmerged 321724 and reassigned it back to libelfg0. Alex, this should be fixable with a simple rebuild of the package. I cannot directly confirm which compiler version was used for building gdbm, but this package was last rebuilt in September 2003, and the binary is missing a PT_GNU_STACK header, so there is a reasonable chance it was built with gcc-2.95. The libgdbm3 package has the same version in sarge and in sid; James, it looks like we may want to try rebuilding gdbm to see if it fixes this problem. Reassigned back to libgdbm3. Both the sarge and the sid versions of libssl0.9.7 were definitely *not* built with gcc-2.95, but they both have a PT_GNU_STACK header in /usr/lib/i686/cmov/libcrypto.so.0.9.7 which explicitly requests an executable stack. This is not the same bug as the others, which were getting an executable stack by default. Since there may be legitimate reasons for requesting an executable stack, I'm downgrading this bug to minor in addition to reassigning it -- anyone playing with grsec/PaX should be prepared for the possibility of having to deal with setting such policies on binaries where needed. The bug against libgcrypt11 is the same as that against libssl0.9.7 -- the library has explicitly requested an executable stack. I don't think this is a coincidence: it's pretty likely that both of these libraries *use* the executable stack, which means there's not much chance of them being fixed. Reassigning and downgrading, in any case. The last bug, I'm leaving assigned to glibc, since that is the package whose behavior change triggered these reports. Of course, this is simply a case of glibc bailing on error from mprotect() rather than silently ignoring the permission issues, so I imagine the glibc maintainers won't do anything with this bug except close it... In any case, none of these bugs are of severity higher than important. There is no policy that Debian supports grsec kernels, and this narrow use case does not otherwise meet the definition of a "grave" or "critical" bug. Thanks, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature