All of lore.kernel.org
 help / color / mirror / Atom feed
From: Solar Designer <solar@openwall.com>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] GNU_STACK policy problem
Date: Sat, 23 Jul 2011 19:06:58 +0400	[thread overview]
Message-ID: <20110723150658.GA11156@openwall.com> (raw)
In-Reply-To: <20110718194803.GA5337@albatros>

Vasiliy, Eugene -

I started looking into this, and here's what I found in RHEL 5 kernels:

kernel/sysctl.c:

int exec_shield = (1<<0);
/* exec_shield is a bitmask:
          0: off; vdso at STACK_TOP, 1 page below TASK_SIZE
   (1<<0) 1: on [also on if !=0]
   (1<<1) 2: force noexecstack regardless of PT_GNU_STACK
   The old settings
   (1<<2) 4: vdso just below .text of main (unless too low)
   (1<<3) 8: vdso just below .text of PT_INTERP (unless too low)
   are ignored because the vdso is placed completely randomly
*/

fs/binfmt_elf.c:

	if (current->personality == PER_LINUX && (exec_shield & 2)) {
		executable_stack = EXSTACK_DISABLE_X;
		current->flags |= PF_RANDOMIZE;
	}
[...]
	if (!(exec_shield & 2) &&
			elf_read_implies_exec(loc->elf_ex, executable_stack))
		current->personality |= READ_IMPLIES_EXEC;

So it appears that setting exec_shield to 3 on these kernels would do
almost what we need.  It could make sense to consider this existing
configuration mechanism for whatever patch we propose for mainline.

(I was not aware of this feature in RHEL 5 before.)

Thanks,

Alexander

  parent reply	other threads:[~2011-07-23 15:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18 19:48 [kernel-hardening] GNU_STACK policy problem Vasiliy Kulikov
2011-07-21 13:03 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-23 15:06 ` Solar Designer [this message]
2011-07-24  8:39   ` [kernel-hardening] " Vasiliy Kulikov
2011-07-24 14:06     ` Solar Designer
2011-07-26 12:07       ` Vasiliy Kulikov
2011-07-23 15:37 ` Solar Designer
2011-08-22  9:34   ` Vasiliy Kulikov
2011-08-22  9:41     ` Solar Designer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110723150658.GA11156@openwall.com \
    --to=solar@openwall.com \
    --cc=kernel-hardening@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.