public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Eric Paris <eparis@parisplace.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Mike Galbraith <efault@gmx.de>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	James Morris <james.l.morris@oracle.com>,
	LSM List <linux-security-module@vger.kernel.org>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/4] ipc: shm and msg fixes
Date: Tue, 24 Sep 2013 11:05:40 +0200	[thread overview]
Message-ID: <524155E4.9040501@colorfullife.com> (raw)
In-Reply-To: <1379981085.2060.18.camel@buesod1.americas.hpqcorp.net>

Hi all,

On 09/24/2013 02:04 AM, Davidlohr Bueso wrote:
>> (In reality, I suspect the reference count is never elevated in
>> practice, so there is only one case that calls the security freeing
>> thing, so this may all be pretty much theoretical, but at least from a
>> logic standpoint the code clearly makes a big deal about the whole
>> refcount and "last user turns off the lights").
> Right, this would/should have come up years ago if it were actually
> occurring in practice.

As far as I see, the only requirement is "last user does kfree()":
spin_lock must be possible and perm.deleted must be valid.

e.g. from msg.c:
>                 rcu_read_lock();
>                 ipc_lock_object(&msq->q_perm);
>
>                 ipc_rcu_putref(msq);
>                 if (msq->q_perm.deleted) {
>                         err = -EIDRM;
>                         goto out_unlock0;
>                 }



> 8<-----------------------------------------
> From: Davidlohr Bueso <davidlohr@hp.com>
> Subject: [PATCH] ipc: fix race with LSMs
>
> Currently, IPC mechanisms do security and auditing related checks under
> RCU. However, since security modules can free the security structure, for
> example, through selinux_[sem,msg_queue,shm]_free_security(), we can race
> if the structure is freed before other tasks are done with it, creating a
> use-after-free condition. Manfred illustrates this nicely, for instance with
> shared mem and selinux:
>
> --> do_shmat calls rcu_read_lock()
> --> do_shmat calls shm_object_check().
>       Checks that the object is still valid - but doesn't acquire any locks.
>       Then it returns.
> --> do_shmat calls security_shm_shmat (e.g. selinux_shm_shmat)
> --> selinux_shm_shmat calls ipc_has_perm()
> --> ipc_has_perm accesses ipc_perms->security
>
> shm_close()
> --> shm_close acquires rw_mutex & shm_lock
> --> shm_close calls shm_destroy
> --> shm_destroy calls security_shm_free (e.g. selinux_shm_free_security)
> --> selinux_shm_free_security calls ipc_free_security(&shp->shm_perm)
> --> ipc_free_security calls kfree(ipc_perms->security)
>
> This patch delays the freeing of the security structures after all RCU readers
> are done. Furthermore it aligns the security life cycle with that of the rest of
> IPC - freeing them based on the reference counter. For situations where we need
> not free security, the current behavior is kept. Linus states:
>
> "... the old behavior was suspect for another reason too: having
> the security blob go away from under a user sounds like it could cause
> various other problems anyway, so I think the old code was at least
> _prone_ to bugs even if it didn't have catastrophic behavior."
>
> I have tested this patch with IPC testcases from LTP on both my quad-core
> laptop and on a 64 core NUMA server. In both cases selinux is enabled, and
> tests pass for both voluntary and forced preemption models. While the mentioned
> races are theoretical (at least no one as reported them), I wanted to make
> sure that this new logic doesn't break anything we weren't aware of.
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>


      parent reply	other threads:[~2013-09-24  9:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16  3:04 [PATCH 0/4] ipc: shm and msg fixes Davidlohr Bueso
2013-09-16  3:04 ` [PATCH 1/4] ipc,shm: fix race with selinux Davidlohr Bueso
2013-09-16  9:23   ` Manfred Spraul
2013-09-16  3:04 ` [PATCH 2/4] ipc,shm: prevent race with rmid in shmat(2) Davidlohr Bueso
2013-09-27  5:45   ` Manfred Spraul
2013-09-27 23:40     ` Davidlohr Bueso
2013-09-16  3:04 ` [PATCH 3/4] ipc,msg: fix race with selinux Davidlohr Bueso
2013-09-16  3:04 ` [PATCH 4/4] ipc,msg: prevent race with rmid in msgsnd,msgrcv Davidlohr Bueso
2013-09-27  5:50   ` Manfred Spraul
2013-09-19 21:22 ` [PATCH 0/4] ipc: shm and msg fixes Davidlohr Bueso
2013-09-20 18:08   ` Eric Paris
2013-09-21 18:30     ` Davidlohr Bueso
2013-09-21 18:58       ` Linus Torvalds
2013-09-23  6:42         ` Davidlohr Bueso
2013-09-23 16:54           ` Linus Torvalds
2013-09-24  0:04             ` Davidlohr Bueso
2013-09-24  1:22               ` Linus Torvalds
2013-09-24  8:49                 ` Manfred Spraul
2013-09-24  9:05               ` Manfred Spraul [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=524155E4.9040501@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=akpm@linux-foundation.org \
    --cc=casey@schaufler-ca.com \
    --cc=davidlohr@hp.com \
    --cc=efault@gmx.de \
    --cc=eparis@parisplace.org \
    --cc=james.l.morris@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=sedat.dilek@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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