linux-kernel - Re: [PATCH] prctl: fix validation of an address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1356964034.31923.12.camel@localhost>
Date:	Mon, 31 Dec 2012 09:27:14 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Andrew Vagin <avagin@...allels.com>
Cc:	Andrey Vagin <avagin@...nvz.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	James Morris <jmorris@...ei.org>
Subject: Re: [PATCH] prctl: fix validation of an address

On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote:
> On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote:
> > On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote:
> > > The address should be bigger than dac_mmap_min_addr, because
> > > a process with CAP_RAWIO can map a vma bellow mmap_min_addr.
> > 
> > NAK
> 
> Currently prctl(PR_SET_MM_*, addr, ) returns EINVAL for valid addresses.
> I think it's a bug. Are you agree?

Can you help me understand how prctl(PR_SET_MM_*, relates to
checkpoint/restore?  My worry here is that somehow this interface could
be used to bypass the security properties of mmap_min_addr.    I have no
idea how the interface is used, so I don't know if my fears are founded.
When I hear 'restore' I think of a privileged application setting up
some unprivileged application based on untrusted data.  My fear is that
some unpriv application, that doesn't have permission to map below
mmap_min_addr, may be able to trick the privileged application, which
would have this permission, into doing it on its behalf.  Does that make
sense?  Is that a realistic scenario with how this interface is used?

> CONFIG_LSM_MMAP_MIN_ADDR could not be got from user space.
> 
> This application can use a real value of mmap_min_addr, but it is not
> provided into userspace.

Unrelated to this patch issue, but I guess either could be exposed if
there is a need.

> Currently a task can have user memory area bellow dac_mmap_min_addr,
> but prctl returns -EINVAL for such addresses.
> How can I understand the reason, if I know that the address is valid?

Talking about dac_mmap_min_addr is wrong.  The capabilities security
module uses dac_mmap_min_addr but other LSMs can (and obviously do) use
other things.  mmap_min_addr is just the shorthand to make sure you
clear all hurdles.  Breaking those hurdles up outside of the security
subsystem is wrong.

The kernel makes the decision on what is valid via security_mmap_addr().
Assuming there are no security fears of an untrusted application
tricking some priviledged application to set up these maps the answer is
just calling security_mmap_addr() instead of doing if(addr <
mmap_min_addr) return -EINVAL;

I don't know if it is a good idea to allow this interface to ever go
below mmap_min_addr, but I do know that using (or even thinking about)
dac_mmap_min_addr is wrong and you should be looking at
security_mmap_addr() if you look at anything...

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/