public inbox for kernel-hardening@lists.openwall.com
 help / color / mirror / Atom feed
From: Vasiliy Kulikov <segoon@openwall.com>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] Trying to get PaX RANDMMAP into the mainstream kernel
Date: Thu, 25 Aug 2011 21:56:02 +0400	[thread overview]
Message-ID: <20110825175602.GA3439@albatros> (raw)
In-Reply-To: <4E56483F.3070701@gentoo.org>

Hi Anthony,

On Thu, Aug 25, 2011 at 09:03 -0400, Anthony G. Basile wrote:
> I had a brief conversation yesterday with solardiz on
> freenode/#openwall.  The topic turned to what other hardening code could
> go upstream besides the stuff you guys have already been pushing.

Sure!  The previous stuff was just a part that I've tried to somehow
handle during a short time window.


>  It
> would be nice if we could get PaX RANDMMAP in.  It gives better
> randomization on mmap addresses, but unfortunately breaks packages which
> use pre-compiled headers. [1]

Am I right that the difference is that upstream mmap() respects addr
hint from userspace and PaX ignores it?


> We came across this issue in a hardened gentoo bug.

Were gcc developers informed about the issue?  There is a small
possibility that they don't mind to fix it :)


> If RANDMMAP does get in, then this would be incentive to the gcc people
> to address the limitations of their gch code.  However, the logic works
> the other way, so this is also the barrier to getting RANDMMAP upstream.
> solardiz had a good idea: have some sysctl in /proc/sys/kernel either
> turn it on or off,

Do you mean ignore addr hint or respect it?  I find it too limited and
upstream is likely to NACK it.

As it is only a hint for OS, it could be simply ignored, without any
sysctl.  But as it breaks at least one widespread application, it's
unlikely to be applied by upstream :(


> or allow you to set the amount of randomization.

Agreed.  sysctl is good for containers, which handle ASLR different way.
E.g. some containers run apps which don't need much VA space, but
another container has space critical applications.


> Also, I don't know if people here are familiar with Hedrick's work.  He
> has broken up the grsec 50k line monolithic patch into smaller patches
> which address each feature individually.  Critical if you want to get
> any of this stuff upstream.

Great, I didn't know about it.  I'll look at it very soon.


Thanks,

-- 
Vasiliy

      reply	other threads:[~2011-08-25 17:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 13:03 [kernel-hardening] Trying to get PaX RANDMMAP into the mainstream kernel Anthony G. Basile
2011-08-25 17:56 ` Vasiliy Kulikov [this message]

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=20110825175602.GA3439@albatros \
    --to=segoon@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox