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]

Date:	Wed, 4 Oct 2006 04:21:27 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

Ulrich Drepper wrote:
>On 10/3/06, David Wagner <daw@...berkeley.edu> wrote:
>> Are you familiar with the mmap(PROT_EXEC, MAP_ANONYMOUS) loophole?
>
>Another person who doesn't know about SELinux.  Read
>
>http://people.redhat.com/drepper/selinux-mem.html

You're right, I didn't know about that one.  Thanks for the
education and for taking the time to respond.

I wonder whether it is feasible to run with allow_exec{heap,mem,mod,stack}
all set to false, on a real system.  Is there any example of a fully
worked out SELinux policy that has these set to false?  FC5 has
allow_execheap set to false and all others set to true in its default
SELinux policy, so it looks like the mmap(PROT_EXEC, MAP_ANONYMOUS)
loophole remains open in FC5 by default.  My concern would be that setting
all of the exec-related booleans to false might break so much code that
setting them all to false wouldn't be feasible in practice.  If so,
the theoretical possibility to close the mmap(PROT_EXEC, MAP_ANONYMOUS)
loophole may be one of these things that is possible in theory but not
in practice.
-
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/