linux-kernel - Re: [patch] remove MNT_NOEXEC check for PROT

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: <Pine.LNX.4.64.0609231555390.27012@blonde.wat.veritas.com>
Date:	Sat, 23 Sep 2006 16:16:51 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Stas Sergeev <stsp@...et.ru>
cc:	Andrew Morton <akpm@...l.org>, Ulrich Drepper <drepper@...hat.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

On Sat, 23 Sep 2006, Stas Sergeev wrote:
> Hi Andrew.
> 
> I am not sure at all whether this patch is appreciated
> or not. The on-list query yielded no results, but I have
> to try. :)

Probably not appreciated :)  I agree with your earlier mail, that
those mmap MNT_NOEXEC checks don't give any watertight protection:
they're more a heuristic to prevent the wrong thing happening
automatically.  But they were put in for good reason, have been
in for nearly three years, I doubt they should come out now.

It's hardly any surprise, is it, that if a distro chooses now
to mount something "noexec", a problem is then found with a few
things which want otherwise?  And it seems unlikely that the answer
is then to modify the kernel, to weaken the very protection they're
wanting to add?

The original 2.6.0 patch (later backported into 2.4.25) was
<drepper@...hat.com>
	[PATCH] Fix 'noexec' behaviour
	
	We should not allow mmap() with PROT_EXEC on mounts marked "noexec",
	since otherwise there is no way for user-supplied executable loaders
	(like ld.so and emulator environments) to properly honour the
	"noexec"ness of the target.
so let's CC Ulrich Drepper in case he's changed his mind on it.

Hugh

> 
> This patch removes the MNT_NOEXEC check for the PROT_EXEC
> mappings. That allows to mount tmpfs with "noexec" option
> without breaking the existing apps, which is what debian
> wants to do for sequrity reasons:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386945
> More details here:
> http://uwsg.ucs.indiana.edu/hypermail/linux/kernel/0609.2/1537.html
> 
> Signed-off-by: Stas Sergeev <stsp@...et.ru>
> 
> --- a/mm/mmap.c	2006-01-25 15:02:24.000000000 +0300
> +++ b/mm/mmap.c	2006-09-21 13:19:15.000000000 +0400
> @@ -899,10 +899,6 @@
>  
>  		if (!file->f_op || !file->f_op->mmap)
>  			return -ENODEV;
> -
> -		if ((prot & PROT_EXEC) &&
> -		    (file->f_vfsmnt->mnt_flags & MNT_NOEXEC))
> -			return -EPERM;
>  	}
>  	/*
>  	 * Does the application expect PROT_READ to imply PROT_EXEC?
> @@ -911,8 +907,7 @@
>  	 *  mounted, in which case we dont add PROT_EXEC.)
>  	 */
>  	if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
> -		if (!(file && (file->f_vfsmnt->mnt_flags & MNT_NOEXEC)))
> -			prot |= PROT_EXEC;
> +		prot |= PROT_EXEC;
>  
>  	if (!len)
>  		return -EINVAL;
> --- a/mm/nommu.c	2006-04-12 09:37:34.000000000 +0400
> +++ b/mm/nommu.c	2006-09-21 13:21:32.000000000 +0400
> @@ -493,13 +493,7 @@
>  				capabilities &= ~BDI_CAP_MAP_DIRECT;
>  		}
>  
> -		/* handle executable mappings and implied executable
> -		 * mappings */
> -		if (file->f_vfsmnt->mnt_flags & MNT_NOEXEC) {
> -			if (prot & PROT_EXEC)
> -				return -EPERM;
> -		}
> -		else if ((prot & PROT_READ) && !(prot & PROT_EXEC)) {
> +		if ((prot & PROT_READ) && !(prot & PROT_EXEC)) {
>  			/* handle implication of PROT_EXEC by PROT_READ */
>  			if (current->personality & READ_IMPLIES_EXEC) {
>  				if (capabilities & BDI_CAP_EXEC_MAP)
-
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/