All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Isaacson <adi@hexapodia.org>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Davide Libenzi <davidel@xmailserver.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness
Date: Fri, 29 Jun 2007 12:39:54 -0700	[thread overview]
Message-ID: <20070629193954.GL9157@hexapodia.org> (raw)
In-Reply-To: <EC4CE052-5514-465E-92D2-9D50DA970DDC@mac.com>

On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
> On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> >So I implemented a rather quick hack that introduces a new mmap()  
> >flag MAP_NOZERO (only valid for anonymous mappings) and the  vma   
> >counter-part VM_NOZERO. Also, a new sys_brk2() has been introduced  
> >to accept a new flags  parameter. A brief description of the  
> >patches follows in the next emails.
> 
> Hmm, sounds like this would also need a "MAP_NOREUSE" flag of some  
> kind for security sensitive applications.  Basically, I wouldn't want  
> my ssh-agent pages holding private SSH keys to be reused by my web  
> browser which then gets exploited :-D.

PGP at least (and I think GPG still) did overwrite keys before calling
free(), and attempted to use mlock().  Looks like ssh-agent doesn't use
mlock -- at least it hasn't in this case:
% grep Lck /proc/`pidof ssh-agent`/status
VmLck:         0 kB
% ulimit -a | grep lock
file size (blocks)         unlimited
core file size (blocks)    0
locked-in-memory size (kb) 32
file locks                 unlimited

Requiring security-sensitive apps to use a new flag to get safe behavior
is dangerous.  Better to be safe by default and turn on the
less-safe-but-faster behavior for the cases that benefit from it.

> It would also be a massive  
> information leak under SELinux.  To fix it properly according to the  
> SELinux model you would need to tag each page with a label  
> immediately after it's freed and then do an access-vector-check  
> against the old page and the new process before allowing reuse.  On  
> the other hand, that would probably be at least as expensive as  
> zeroing the page.

I still think that using uid in mm_struct is wrong, and some kind of
abstraction is required.  I called this "free pool" in
<20070628061911.GA16986@hexapodia.org>, but I think that name is
misleading -- I am not proposing that this should be part of the
management of free pages, but should be a label which abstracts "safe to
share freed pages among" groups.  Then different SELinux protection
domains would simply have different labels.

-andy

  parent reply	other threads:[~2007-06-29 19:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-28 18:49 [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness Davide Libenzi
2007-06-29  2:57 ` Kyle Moffett
2007-06-29  3:04   ` Rik van Riel
2007-06-29  5:09     ` Ulrich Drepper
2007-06-29  5:20   ` Davide Libenzi
2007-06-29 19:39   ` Andy Isaacson [this message]
2007-06-29 20:12     ` Davide Libenzi
2007-06-29 23:48       ` Kyle Moffett
2007-06-30 19:03         ` Davide Libenzi
2007-06-30 23:46           ` Kyle Moffett
2007-06-30 23:57             ` Davide Libenzi
2007-07-01  0:21               ` Kyle Moffett
2007-07-01  4:25                 ` Davide Libenzi
2007-07-02 19:00                 ` Andy Isaacson
2007-07-02 19:03                   ` Rik van Riel
2007-07-02 19:06                     ` Ulrich Drepper
2007-07-02 22:46                       ` Davide Libenzi
2007-07-02 22:55                         ` Rik van Riel
2007-07-02 23:46                           ` Davide Libenzi
2007-07-04 21:53                           ` Andy Isaacson
2007-07-04 23:42                             ` Davide Libenzi
2007-07-02 18:38           ` Andy Isaacson
2007-07-02 22:38             ` Davide Libenzi

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=20070629193954.GL9157@hexapodia.org \
    --to=adi@hexapodia.org \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.com \
    --cc=riel@redhat.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.