Date: Wed, 22 Feb 2012 01:00:06 +0400 From: Solar Designer <solar@...nwall.com> To: owl-dev@...ts.openwall.com Cc: Brad Spengler <spender@...ecurity.net> Subject: CONFIG_GRKERNSEC_PTRACE_READEXEC Hi, I am posting this to owl-dev rather than to kernel-hardening because it's mostly specific to our older kernels. I briefly looked into getting grsecurity's CONFIG_GRKERNSEC_PTRACE_READEXEC feature (protecting against reads of otherwise unreadable SUID/SGID binaries via ptrace) into the RHEL5'ish kernels that we currently use on Owl. It appears that this is not as straightforward as I would have liked it to be. So we'll probably postpone this until after we migrate to RHEL6'ish kernels. Specifically, in grsecurity-2.2.2-126.96.36.199-201202200919.patch, a call to gr_ptrace_readexec() is introduced near the beginning of do_execve(), before the point of no return. By that time, prepare_bprm_creds() has already been called, and it holds current->cred_guard_mutex, which (I think) protects against further ptrace attaches. However, in RHEL5'ish kernels, there's no prepare_bprm_creds(), and instead further ptrace attaches are only prevented (as far as I can see) when setup_new_exec() does "current->mm->dumpable = suid_dumpable;". setup_new_exec() is called from load_elf_binary(), which is called from search_binary_handler() late during execve(). When nearby calls from load_elf_binary() fail, it does "send_sig(SIGKILL, current, 0);", and in fact it can be seen that the old program is already partially destroyed by that time. BTW, I vaguely recall that it's difficulties like this that prevented me and others from patching this before (on 2.4 kernels). IIRC, this problem was introduced somewhere between 2.2 and 2.4 (we had ptraced SUID/SGID exec properly fail on older kernels - it definitely did on 2.0, and IIRC it did on 2.2 as well). Now I'm not brave enough to re-order calls in our RHEL5'ish kernels, nor to introduce an extra SIGKILL condition (although it's probably harmless), nor to introduce protection against new ptrace attaches earlier in execve() (although it should be safe and even beneficial on its own if done right). We'll get the better code soon anyway (and then we'll be able to just apply Brad's change almost as-is), things were this way (and known) for a decade, and the impact is minimal. Unfortunately, I only had very little time to put into this, and my further time is probably better spent on moving our project forward rather than on not-so-trivial patching (and testing) of this legacy kernel that we'll hopefully move away from soon. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.