linux-kernel - Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 15 May 2012 16:07:26 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Eric Paris <eparis@...isplace.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mimi Zohar <zohar@...ibm.com>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

On Tue, 2012-05-15 at 15:42 -0400, Eric Paris wrote:
> On Tue, May 15, 2012 at 2:41 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Tue, May 15, 2012 at 10:19 AM, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> >>
> >>  - move the whole call to security_file_mmap() to outside the
> >> mmap_sem, and test the *suggested* address (which is not the same as
> >> the final address)
> >
> > Actually, I think I have a simpler approach.
> >
> > We already actually have two *different* security_file_mmap() calls:
> > it's just that currently the difference is shown by the last argument
> > to the function ("addr_only").
> 
> I'm the one who introduced that bit of horrific.  I originally did it
> the way you describe and someone (it was a long time ago, and I think
> it was Ted Tso, but I am probably very very wrong on that) ask me to
> tack it on the end like this.  I'd be very happy with the split you
> describe.
> 
> I'd rather not, however, move the address call site like you described
> above, as I don't want to allow NULL + ~MAP_FIXED to be tested until
> it has been resolved to a real address.  I don't want someone to find
> a way to get the kernel to choose 4096 and avoid the check....

If the security_file_mmap() moves to before taking the mmap_sem and the
new security_mmap_addr() hook would be at the current
security_file_mmap() location, I don't see the problem.  The addr test
would remain in the same place.

> Mimi, would you like to do this (slightly) larger change?  Should I?

np, I'll make the changes.

Mimi

--
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/