public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox