[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120221210006.GA24836@openwall.com>
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-2.6.32.57-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.
