runit running under linux 2.4 with openwall patches

runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]

One of the features of openwall is stack protection.  I'm getting this 
when I try to boot into a 2.4.29 kernel with openwall hardening 
enabled:

Security: return onto stack from 0x0804812c to 0xbffffea0 running as 
UID 0, EUID 0, process runit:1
Security more returns onto stack, logging disabled for a minute

I can manage to make the kernel boot, but runit isn't running and it's 
consuming 100% cpu in my vmware test machine.

I have two ideas that may be causing the problem, and not being a 
kernel person I don't really know for 100% which it is:

1) the Non-executable user stack area part of owl
2) the enforce RLIMIT_NPROC on execve(2)

I have a feeling that it's #1 tho.  The question is, why is runit doing 
this?  This is a valuable feature to have in a security-hardened 
distro, and having runit not running because of it is problematic.  I'd 
like to be able to do both (although, for testing, I'm going to compile 
another kernel with this feature disabled just to isolate it).  The 
description of the feature according to 
http://www.openwall.com/linux/README.shtml is:

===
Most buffer overflow exploits are based on overwriting a function's 
return address on the stack to point to some arbitrary code, which is 
also put onto the stack. If the stack area is non-executable, buffer 
overflow vulnerabilities become harder to exploit.

  Another way to exploit a buffer overflow is to point the return 
address to a function in libc, usually system(). This patch also 
changes the default address that shared libraries are mmap()'ed at to 
make it always contain a zero byte. This makes it impossible to specify 
any more data (parameters to the function, or more copies of the return 
address when filling with a pattern), -- in many exploits that have to 
do with ASCIIZ strings.

  However, note that this patch is by no means a complete solution, it 
just adds an extra layer of security. Many buffer overflow 
vulnerabilities will remain exploitable a more complicated way, and 
some will even remain unaffected by the patch. The reason for using 
such a patch is to protect against some of the buffer overflow 
vulnerabilities that are yet unknown.

  Also, note that some buffer overflows can be used for denial of 
service attacks (usually in non-respawning daemons and network 
clients). A patch like this cannot do anything against that.

  It is important that you fix vulnerabilities as soon as they become 
known, even if you're using the patch. The same applies to other 
features of the patch (discussed below) and their corresponding 
vulnerabilities.
===

I'd like to be able to have both runit and this feature together; I 
think it should be possible because the traditional init works with it. 
  Any ideas on how to go about this?

Right now I'm using runit 1.0.5 but plan to upgrade it soon; is this 
something that may have been addressed in more recent versions?

Thanks for any info.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Charlie Brady]

On Thu, 20 Jan 2005, Vincent Danen wrote:

> One of the features of openwall is stack protection.  I'm getting this 
> when I try to boot into a 2.4.29 kernel with openwall hardening 
> enabled:
> 
> Security: return onto stack from 0x0804812c to 0xbffffea0 running as 
> UID 0, EUID 0, process runit:1
> Security more returns onto stack, logging disabled for a minute
> 
> I can manage to make the kernel boot, but runit isn't running and it's 
> consuming 100% cpu in my vmware test machine.
> 
> I have two ideas that may be causing the problem, and not being a 
> kernel person I don't really know for 100% which it is:
> 
> 1) the Non-executable user stack area part of owl
> 2) the enforce RLIMIT_NPROC on execve(2)
> 
> I have a feeling that it's #1 tho.

Why do you have that feeling? What gives you these two ideas? Do you see 
any actions from runit before the "return onto stack" message?

You might run "strace runit-init" in place of "runit", although I'm not 
sure what chaos that might cause.

Re: runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]


On Jan 20, 2005, at 15:28, Charlie Brady wrote:

>> One of the features of openwall is stack protection.  I'm getting this
>> when I try to boot into a 2.4.29 kernel with openwall hardening
>> enabled:
>>
>> Security: return onto stack from 0x0804812c to 0xbffffea0 running as
>> UID 0, EUID 0, process runit:1
>> Security more returns onto stack, logging disabled for a minute
>>
>> I can manage to make the kernel boot, but runit isn't running and it's
>> consuming 100% cpu in my vmware test machine.
>>
>> I have two ideas that may be causing the problem, and not being a
>> kernel person I don't really know for 100% which it is:
>>
>> 1) the Non-executable user stack area part of owl
>> 2) the enforce RLIMIT_NPROC on execve(2)
>>
>> I have a feeling that it's #1 tho.
>
> Why do you have that feeling? What gives you these two ideas? Do you 
> see
> any actions from runit before the "return onto stack" message?

Well, for one, it's explicitly stating runit (ie. process runit:1).  
For two, runit is starting, but when runit should be switching to stage 
2, I keep getting these errors and pretty much nothing is happening.

The kernel boots, the fs is mounted, and the first error is before the 
traditional initscripts, which runit runs, is done.  Those initscripts 
execute fine without error, but when runit should be switching to stage 
2, all I get are these errors being reported with CPU climbing.

> You might run "strace runit-init" in place of "runit", although I'm not
> sure what chaos that might cause.

Well, it is in vmware so doesn't really matter... =)  I'll just take a 
snapshot first.  The fact that the kernel is pretty much pointing out 
runit each time leads me to believe it's, well, runit.  I'm not sure 
what runit is doing when it's entering it's stages, but whatever it is 
doing might be what is causing the owl-patched-kernel to freak out.

BTW, I just compiled and upgraded to runit 1.2.1 and see the same 
behaviour.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Gerrit Pape]

On Thu, Jan 20, 2005 at 03:14:38PM -0700, Vincent Danen wrote:
> One of the features of openwall is stack protection.  I'm getting this 
> when I try to boot into a 2.4.29 kernel with openwall hardening 
> enabled:
> 
> Security: return onto stack from 0x0804812c to 0xbffffea0 running as 
> UID 0, EUID 0, process runit:1
> Security more returns onto stack, logging disabled for a minute
> 
> I can manage to make the kernel boot, but runit isn't running and it's 
> consuming 100% cpu in my vmware test machine.

Hm, I don't know the openwall patch and what in runit.c could cause
this.

> I'd like to be able to have both runit and this feature together; I 
> think it should be possible because the traditional init works with it. 
>  Any ideas on how to go about this?

Did you link the runit program statically with the dietlibc?  If so, you
could try to compile it the same way as the working /sbin/init, to be
sure it's not the compiler or libc causing the problem.

Regards, Gerrit.

Re: runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]


On Jan 21, 2005, at 12:32, Gerrit Pape wrote:

>> One of the features of openwall is stack protection.  I'm getting this
>> when I try to boot into a 2.4.29 kernel with openwall hardening
>> enabled:
>>
>> Security: return onto stack from 0x0804812c to 0xbffffea0 running as
>> UID 0, EUID 0, process runit:1
>> Security more returns onto stack, logging disabled for a minute
>>
>> I can manage to make the kernel boot, but runit isn't running and it's
>> consuming 100% cpu in my vmware test machine.
>
> Hm, I don't know the openwall patch and what in runit.c could cause
> this.

I have a feeling it's the stack protection, but why is the trick 
question.

>> I'd like to be able to have both runit and this feature together; I
>> think it should be possible because the traditional init works with 
>> it.
>>  Any ideas on how to go about this?
>
> Did you link the runit program statically with the dietlibc?  If so, 
> you
> could try to compile it the same way as the working /sbin/init, to be
> sure it's not the compiler or libc causing the problem.

That's a good idea.  I did compile it statically with dietlibc.  I'll 
try without dietlibc and see what happens.  I haven't had a chance to 
dive back into it yet, but when I get a second I'll rebuild it and see 
if that clears it up.  If not, I'll recompile the kernel without the 
stack protection option enabled, just to make sure that it is what I 
think it is.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Torne Wuff]

Quoting Vincent Danen <vdanen@annvix.org>:
> > Did you link the runit program statically with the dietlibc?  If so,
> > you
> > could try to compile it the same way as the working /sbin/init, to be
> > sure it's not the compiler or libc causing the problem.
>
> That's a good idea.  I did compile it statically with dietlibc.  I'll
> try without dietlibc and see what happens.  I haven't had a chance to
> dive back into it yet, but when I get a second I'll rebuild it and see
> if that clears it up.  If not, I'll recompile the kernel without the
> stack protection option enabled, just to make sure that it is what I
> think it is.

Yes, it's dietlibc. Dietlibc executes code from the stack during system calls,
afaict.

-- 
Torne

Re: runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]


On Jan 25, 2005, at 3:58, Torne Wuff wrote:

> Quoting Vincent Danen <vdanen@annvix.org>:
>>> Did you link the runit program statically with the dietlibc?  If so,
>>> you
>>> could try to compile it the same way as the working /sbin/init, to be
>>> sure it's not the compiler or libc causing the problem.
>>
>> That's a good idea.  I did compile it statically with dietlibc.  I'll
>> try without dietlibc and see what happens.  I haven't had a chance to
>> dive back into it yet, but when I get a second I'll rebuild it and see
>> if that clears it up.  If not, I'll recompile the kernel without the
>> stack protection option enabled, just to make sure that it is what I
>> think it is.
>
> Yes, it's dietlibc. Dietlibc executes code from the stack during 
> system calls,
> afaict.

Interesting.  Time will tell... I'll be testing it in a few hours after 
I take care of some "real" work.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]


On Jan 25, 2005, at 3:58, Torne Wuff wrote:

> Quoting Vincent Danen <vdanen@annvix.org>:
>>> Did you link the runit program statically with the dietlibc?  If so,
>>> you
>>> could try to compile it the same way as the working /sbin/init, to be
>>> sure it's not the compiler or libc causing the problem.
>>
>> That's a good idea.  I did compile it statically with dietlibc.  I'll
>> try without dietlibc and see what happens.  I haven't had a chance to
>> dive back into it yet, but when I get a second I'll rebuild it and see
>> if that clears it up.  If not, I'll recompile the kernel without the
>> stack protection option enabled, just to make sure that it is what I
>> think it is.
>
> Yes, it's dietlibc. Dietlibc executes code from the stack during 
> system calls,
> afaict.

Well, it's definitely dietlibc.  I compiled runit with glibc 
(statically) and it works just fine.   Very strange.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Csillag Tamás]

Hi

On 01/25, Vincent Danen wrote:
> 
> On Jan 25, 2005, at 3:58, Torne Wuff wrote:
...
> >Yes, it's dietlibc. Dietlibc executes code from the stack during 
> >system calls,
> >afaict.
> 
> Well, it's definitely dietlibc.  I compiled runit with glibc 
> (statically) and it works just fine.   Very strange.
I got the same with grsecurity (www.grsecurity.org).
Well it did not stated exactly in the log that the stack operation is the
cause of killing that process.

It could happen for *all* dietlibc linked program.
(I experienced in: runsv svlogd fnord tcpsvd ... )

In grsec I use the chpax utility to bypass this security checks on these
(and only these) programs.

Maybe it is worth asking the author of dietlibc..
http://www.fefe.de/dietlibc/

-- 
cstamas

Re: runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]


On Jan 25, 2005, at 17:44, Csillag Tamás wrote:

>>> Yes, it's dietlibc. Dietlibc executes code from the stack during
>>> system calls,
>>> afaict.
>>
>> Well, it's definitely dietlibc.  I compiled runit with glibc
>> (statically) and it works just fine.   Very strange.
> I got the same with grsecurity (www.grsecurity.org).
> Well it did not stated exactly in the log that the stack operation is 
> the
> cause of killing that process.
>
> It could happen for *all* dietlibc linked program.
> (I experienced in: runsv svlogd fnord tcpsvd ... )

Odd thing here is that I tried a few other apps that were 
dietlibc-compiled and didn't see a problem.

Hmmm... spoke too soon.  None of the services requiring tcpsvd were 
installed, so I tried with rsync and if I start supervise on those 
services, nothing happens.  But if "sh -x run" myself, I can see the 
services are starting.  Not sure if recompiling ipsvd without dietlibc 
will help, but it's something I'll have to try.

> In grsec I use the chpax utility to bypass this security checks on 
> these
> (and only these) programs.

Ouch.  Not a good solution.

> Maybe it is worth asking the author of dietlibc..
> http://www.fefe.de/dietlibc/

I have... and am in the middle of a conversation with him.  He's very 
interested in seeing this resolved.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Csillag Tamás]

I am sorry if this is a bit OT here.

On 01/25, Vincent Danen wrote:
> 
> On Jan 25, 2005, at 17:44, Csillag Tamás wrote:
> 
> >>>Yes, it's dietlibc. Dietlibc executes code from the stack during
> >>>system calls,
> >>>afaict.
> >>
> >>Well, it's definitely dietlibc.  I compiled runit with glibc
> >>(statically) and it works just fine.   Very strange.
> >I got the same with grsecurity (www.grsecurity.org).
> >Well it did not stated exactly in the log that the stack operation is 
> >the
> >cause of killing that process.
> >
> >It could happen for *all* dietlibc linked program.
> >(I experienced in: runsv svlogd fnord tcpsvd ... )
> 
> Odd thing here is that I tried a few other apps that were 
> dietlibc-compiled and didn't see a problem.
> 
> Hmmm... spoke too soon.  None of the services requiring tcpsvd were 
> installed, so I tried with rsync and if I start supervise on those 
> services, nothing happens.  But if "sh -x run" myself, I can see the 
> services are starting.  Not sure if recompiling ipsvd without dietlibc 
> will help, but it's something I'll have to try.
You cannot predict when will it happen.
In fnord-cgi it only happend when it executed the cgis. I blamed myself
that something is missing inside it's chroot, but it worked well if I
ran it 'strace -f' (I mean fnord).

In runsv when you signal a service runsv itself gets killed, and
runsvdir will restart it (you can see that log -service has the same
'uptime' as the supervisioned process).
> 
> >In grsec I use the chpax utility to bypass this security checks on 
> >these
> >(and only these) programs.
> 
> Ouch.  Not a good solution.
> 
> >Maybe it is worth asking the author of dietlibc..
> >http://www.fefe.de/dietlibc/
> 
> I have... and am in the middle of a conversation with him.  He's very 
> interested in seeing this resolved.
Nice. 
It is not on the dietlibc -list is not it?
(I do not see it there)
Please send me a summary when it gets resolved.

(Maybe here too, I think the guys maybe also interested in this,
and if you already started it here ;-)

Thanks.

-- 
cstamas

Re: runit running under linux 2.4 with openwall patches

[Milan P. Stanic]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Tue, Jan 25, 2005 at 09:31:48PM -0700, Vincent Danen wrote:
> 
> On Jan 25, 2005, at 17:44, Csillag Tamás wrote:
> 
> >>>Yes, it's dietlibc. Dietlibc executes code from the stack during
> >>>system calls,
> >>>afaict.
> >>
> >>Well, it's definitely dietlibc.  I compiled runit with glibc
> >>(statically) and it works just fine.   Very strange.
> >I got the same with grsecurity (www.grsecurity.org).
> >Well it did not stated exactly in the log that the stack operation is 
> >the
> >cause of killing that process.
> >
> >It could happen for *all* dietlibc linked program.
> >(I experienced in: runsv svlogd fnord tcpsvd ... )
> 
> Odd thing here is that I tried a few other apps that were 
> dietlibc-compiled and didn't see a problem.
> 
> Hmmm... spoke too soon.  None of the services requiring tcpsvd were 
> installed, so I tried with rsync and if I start supervise on those 
> services, nothing happens.  But if "sh -x run" myself, I can see the 
> services are starting.  Not sure if recompiling ipsvd without dietlibc 
> will help, but it's something I'll have to try.
> 
> >In grsec I use the chpax utility to bypass this security checks on 
> >these
> >(and only these) programs.
> 
> Ouch.  Not a good solution.
> 
> >Maybe it is worth asking the author of dietlibc..
> >http://www.fefe.de/dietlibc/
> 
> I have... and am in the middle of a conversation with him.  He's very 
> interested in seeing this resolved.

Few months ago I noticed that *any* program which is compiled/linked with
dietlibc segfaults under UML. Same programs with glibc works.
I don't know if this is related to grsec problem but maybe this info
can help.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Charlie Brady]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1487 bytes --]


On Wed, 26 Jan 2005, Csillag[iso-8859-2] Tamás wrote:

> On 01/25, Vincent Danen wrote:
> > 
> > Odd thing here is that I tried a few other apps that were 
> > dietlibc-compiled and didn't see a problem.

That would depend on which functions were called, I would think.

> > Hmmm... spoke too soon.  None of the services requiring tcpsvd were 
> > installed, so I tried with rsync and if I start supervise on those 
> > services, nothing happens.  But if "sh -x run" myself, I can see the 
> > services are starting.  Not sure if recompiling ipsvd without dietlibc 
> > will help, but it's something I'll have to try.
> You cannot predict when will it happen.
> In fnord-cgi it only happend when it executed the cgis. I blamed myself
> that something is missing inside it's chroot, but it worked well if I
> ran it 'strace -f' (I mean fnord).
> 
> In runsv when you signal a service runsv itself gets killed, and
> runsvdir will restart it (you can see that log -service has the same
> 'uptime' as the supervisioned process).

That would suggest to me that the service is relaying the signal to its 
process group, and that process group includes the supervising runsv. 
Apache2 is known to do this, for instance.

Note that runsvdir will not restart the previously running service if 
runsv dies and there is a down file present.

I still think that it would be better for runsv to protect itself from 
such errors by creating a new process group before it execs "run".

---
Charlie

Re: runit running under linux 2.4 with openwall patches

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]


On Feb 05, 2005, at 14:25, Csillag Tamás wrote:

>> Hmmm... spoke too soon.  None of the services requiring tcpsvd were
>> installed, so I tried with rsync and if I start supervise on those
>> services, nothing happens.  But if "sh -x run" myself, I can see the
>> services are starting.  Not sure if recompiling ipsvd without dietlibc
>> will help, but it's something I'll have to try.
>>
>>> In grsec I use the chpax utility to bypass this security checks on
>>> these
>>> (and only these) programs.
>>
>> Ouch.  Not a good solution.
>>
>>> Maybe it is worth asking the author of dietlibc..
>>> http://www.fefe.de/dietlibc/
>>
>> I have... and am in the middle of a conversation with him.  He's very
>> interested in seeing this resolved.
>
> Can you tell me what is the result?
> Felix released 0.28 recently, it contains the fixes for that or not?
> (I was unable to figure out from the CHANGES file)

I meant to email the list earlier, but didn't get a chance.  I did 
build dietlibc 0.28 and recompiled runit under it and it seems to work 
ok.  At least the kernel doesn't kill or stall runit anymore.  But I 
had to build without WANT_STACKGAP due to my gcc+SSP compiler (I don't 
know if this will make any difference to runit itself because I can't 
compiled dietlibc 0.28 with gcc+SSP with WANT_STACKGAP enabled).

So far it seems good although I want to keep an eye on it more before I 
put it into production.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: runit running under linux 2.4 with openwall patches

[Csillag Tamás]

On 02/05, Vincent Danen wrote:
> 
> On Feb 05, 2005, at 14:25, Csillag Tamás wrote:
> 
> >>Hmmm... spoke too soon.  None of the services requiring tcpsvd were
> >>installed, so I tried with rsync and if I start supervise on those
> >>services, nothing happens.  But if "sh -x run" myself, I can see the
> >>services are starting.  Not sure if recompiling ipsvd without dietlibc
> >>will help, but it's something I'll have to try.
> >>
> >>>In grsec I use the chpax utility to bypass this security checks on
> >>>these
> >>>(and only these) programs.
> >>
> >>Ouch.  Not a good solution.
> >>
> >>>Maybe it is worth asking the author of dietlibc..
> >>>http://www.fefe.de/dietlibc/
> >>
> >>I have... and am in the middle of a conversation with him.  He's very
> >>interested in seeing this resolved.
> >
> >Can you tell me what is the result?
> >Felix released 0.28 recently, it contains the fixes for that or not?
> >(I was unable to figure out from the CHANGES file)
> 
> I meant to email the list earlier, but didn't get a chance.  I did 
> build dietlibc 0.28 and recompiled runit under it and it seems to work 
> ok.  At least the kernel doesn't kill or stall runit anymore.  But I 
> had to build without WANT_STACKGAP due to my gcc+SSP compiler (I don't 
> know if this will make any difference to runit itself because I can't 
> compiled dietlibc 0.28 with gcc+SSP with WANT_STACKGAP enabled).
> 
> So far it seems good although I want to keep an eye on it more before I 
> put it into production.

I can confirm it really works. Felix fixed it in this release!

Gerrit, is it possible to push these changes to sarge before release?
I mean dietlibc linked programs

TIA

-- 
cstamas

Re: runit running under linux 2.4 with openwall patches

[Gerrit Pape]

On Mon, Mar 14, 2005 at 03:11:46PM +0100, Csillag Tamás wrote:
> On 02/05, Vincent Danen wrote:
> > On Feb 05, 2005, at 14:25, Csillag Tamás wrote:
> > I meant to email the list earlier, but didn't get a chance.  I did 
> > build dietlibc 0.28 and recompiled runit under it and it seems to work 
> > ok.  At least the kernel doesn't kill or stall runit anymore.  But I 
> > had to build without WANT_STACKGAP due to my gcc+SSP compiler (I don't 
> > know if this will make any difference to runit itself because I can't 
> > compiled dietlibc 0.28 with gcc+SSP with WANT_STACKGAP enabled).
> > 
> > So far it seems good although I want to keep an eye on it more before I 
> > put it into production.
> 
> I can confirm it really works. Felix fixed it in this release!
> 
> Gerrit, is it possible to push these changes to sarge before release?
> I mean dietlibc linked programs

Possibly.  What actually is needed?  Disable STACKGAP in dietlibc, or
just a re-build of the dependent packages with the current dietlibc 0.28
in Debian?  Best would be you submit a report to the Debian BTS.

Regards, Gerrit.