supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* runit running under linux 2.4 with openwall patches
@ 2005-01-20 22:14 Vincent Danen
  2005-01-20 22:28 ` Charlie Brady
  2005-01-21 19:32 ` Gerrit Pape
  0 siblings, 2 replies; 16+ messages in thread
From: Vincent Danen @ 2005-01-20 22:14 UTC (permalink / raw)


[-- 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 --]

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-03-14 17:40 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-20 22:14 runit running under linux 2.4 with openwall patches Vincent Danen
2005-01-20 22:28 ` Charlie Brady
2005-01-20 22:52   ` Vincent Danen
2005-01-21 19:32 ` Gerrit Pape
2005-01-25  4:51   ` Vincent Danen
2005-01-25 10:58     ` Torne Wuff
2005-01-25 19:54       ` Vincent Danen
2005-01-25 23:33       ` Vincent Danen
2005-01-26  0:44         ` Csillag Tamás
2005-01-26  4:31           ` Vincent Danen
2005-01-26  8:52             ` Csillag Tamás
2005-01-27 19:52               ` Charlie Brady
2005-01-26 12:07             ` Milan P. Stanic
     [not found]             ` <20050205212555.GI20427@digitus>
2005-02-05 23:14               ` Vincent Danen
2005-03-14 14:11                 ` Csillag Tamás
2005-03-14 17:40                   ` Gerrit Pape

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).