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]

Message-ID: <20120530202427.GW11775@ZenIV.linux.org.uk>
Date:	Wed, 30 May 2012 21:24:27 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Eric Paris <eparis@...isplace.org>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mimi Zohar <zohar@...ibm.com>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

On Wed, May 30, 2012 at 03:42:47PM -0400, Eric Paris wrote:
> security_file_mmap() would pretty much only be used in do_mmap_pgoff()
> (or validate_mmap_request)

Callers, actually - the whole point is to lift it out of under ->mmap_sem.
The tricky part is reqprot vs. prot mess.

In all cases, we need current to be READ_IMPLIES_EXEC and prot to contain
PROT_READ for any changes to happen.  Assuming that both conditions are
met, we have the following:
file == NULL:
	add PROT_EXEC in !MMU case, don't do that for MMU.
file != NULL, lives on fs mounted noexec: don't modify prot
file != NULL, lives on fs mounted without noexec:
	MMU - add PROT_EXEC; !MMU - add it only if we have BDI_CAP_EXEC_MAP on
that file.

AFAICS, the least painful way of dealing with that would be to have
something like
mangle_prot(struct file *file, unsigned long *prot, unsigned long flags)

that would handle that logics and call security_file_mmap().  With separate
instances in MMU and !MMU cases ;-/  However, there's an extra fun in there -
consider fs/aio.c caller of do_mmap().  For MMU case we don't really care.
But what about !MMU?  Should that guy get PROT_EXEC slapped on it?
--
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/