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}