From: Kyle Moffett <mrmacman_g4@mac.com>
To: daw-usenet@taverner.cs.berkeley.edu (David Wagner)
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps
Date: Wed, 4 Oct 2006 02:03:18 -0400 [thread overview]
Message-ID: <E4468D90-DABA-4622-983F-594B40EBE152@mac.com> (raw)
In-Reply-To: <efvcs7$526$1@taverner.cs.berkeley.edu>
On Oct 04, 2006, at 00:21:27, David Wagner wrote:
> Ulrich Drepper wrote:
>> On 10/3/06, David Wagner <daw@cs.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.
Yes it is; I have done so with a custom SELinux policy before
although it was a company-proprietary policy and I can't share it on
the LKML. It does fairly severely restrict certain binaries,
especially ones like the Java VM or anything else with a Just-in-Time
compiler. You can make it completely impossible for any non-admin-
originated executable or library to ever make it out to any kind of
storage from which it could be run. It's still possible to
compromise a currently-running instance of a binary; but it's
impossible to maintain that compromise across a restart of the
appropriate server process. With appropriate restrictions and
compliant hardware it's even easy to make it impossible to write to
any PROT_EXEC memory or remap any writable memory as PROT_EXEC.
Such protections require a fair amount of tinkering with userspace
and SELinux security policy, but in combination with address-space
randomization makes it extremely difficult or impossible to exploit a
stack-smash or buffer-overflow bug beyond a DoS.
It also conveniently lets you lock down a box to the point where even
root is a meaningless concept. I've helped architect one box where
you have to log in as a rootstaff user with your PKI keycard on the
local console and then enter a second password to transition to the
rootadmin role and from _there_ you have what's considered "ordinary"
root privs, but you don't even have to have that access.
> 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.
No, it's doable but it breaks Java and WINE and a number of other
programs where you _want_ to allow modifiable code.
> 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.
Oh, it's very possible in practice; but for an average distro it's
not useful to prohibit writable code. There's too many insecure
things that users want to do that require it. Just please don't
break the extra security for those of us who don't need Java or WINE
and are willing to fix the odd broken program.
Cheers,
Kyle Moffett
next prev parent reply other threads:[~2006-10-04 6:03 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-23 10:30 Stas Sergeev
2006-09-23 15:16 ` Hugh Dickins
2006-09-23 15:36 ` Ulrich Drepper
2006-09-23 15:47 ` Stas Sergeev
2006-09-25 1:12 ` Valdis.Kletnieks
2006-09-25 4:35 ` Stas Sergeev
2006-09-23 15:42 ` Stas Sergeev
2006-09-23 16:04 ` Hugh Dickins
2006-09-23 16:38 ` Stas Sergeev
2006-09-23 18:58 ` Alan Cox
2006-09-24 6:55 ` Stas Sergeev
2006-09-24 9:17 ` Hugh Dickins
2006-09-24 10:00 ` Stas Sergeev
2006-09-24 13:53 ` Alan Cox
2006-09-24 14:54 ` Stas Sergeev
2006-09-24 15:48 ` Ulrich Drepper
2006-09-24 16:31 ` Stas Sergeev
2006-09-24 16:49 ` Ulrich Drepper
2006-09-24 17:04 ` Stas Sergeev
2006-09-24 18:09 ` Stas Sergeev
2006-09-24 19:14 ` David Wagner
2006-09-24 19:37 ` Kyle Moffett
2006-09-24 22:49 ` David Wagner
2006-09-25 10:53 ` Pavel Machek
2006-09-25 21:36 ` David Wagner
2006-09-27 11:51 ` Pavel Machek
2006-09-24 20:06 ` Denis Vlasenko
2006-09-24 20:22 ` Stas Sergeev
2006-09-24 23:04 ` David Wagner
2006-09-26 19:46 ` Stas Sergeev
2006-09-27 22:33 ` Arjan van de Ven
2006-09-27 23:10 ` David Wagner
2006-09-27 23:38 ` Jesper Juhl
2006-09-29 1:14 ` David Wagner
2006-09-28 4:52 ` Stas Sergeev
2006-09-30 9:42 ` Stas Sergeev
2006-10-03 15:01 ` Arjan van de Ven
2006-10-03 17:15 ` Stas Sergeev
2006-10-03 17:23 ` Ulrich Drepper
2006-10-03 18:06 ` Stas Sergeev
2006-10-03 19:19 ` Ulrich Drepper
2006-10-03 19:40 ` Stas Sergeev
2006-10-03 19:54 ` Arjan van de Ven
2006-10-04 19:36 ` Stas Sergeev
2006-10-04 21:31 ` David Wagner
2006-10-04 3:11 ` David Wagner
2006-10-04 3:51 ` Ulrich Drepper
2006-10-04 4:21 ` David Wagner
2006-10-04 6:03 ` Kyle Moffett [this message]
2006-10-04 17:30 ` Ulrich Drepper
2006-10-03 18:23 ` Arjan van de Ven
2006-10-03 18:40 ` Stas Sergeev
2006-10-03 18:42 ` Arjan van de Ven
2006-10-03 19:07 ` Stas Sergeev
2006-10-03 21:00 ` Jakub Jelinek
2006-10-04 19:06 ` Stas Sergeev
2006-10-06 18:09 ` [patch] honour MNT_NOEXEC for access() Stas Sergeev
2006-10-06 21:34 ` Alan Cox
2006-10-06 21:17 ` Ulrich Drepper
2006-10-07 11:19 ` Stas Sergeev
2006-10-07 15:00 ` David Wagner
2006-10-07 16:31 ` Ulrich Drepper
2006-10-07 19:14 ` Stas Sergeev
2006-10-07 19:36 ` David Wagner
2006-10-08 8:32 ` Arjan van de Ven
2006-10-08 9:11 ` Stas Sergeev
2006-10-08 10:55 ` Arjan van de Ven
2006-10-08 13:46 ` Stas Sergeev
2006-10-09 2:09 ` Horst H. von Brand
2006-10-09 4:40 ` Stas Sergeev
2006-10-07 13:18 ` Stas Sergeev
2006-10-08 0:30 ` Jeremy Fitzhardinge
2006-10-08 9:10 ` Stas Sergeev
2006-10-08 9:56 ` Jeremy Fitzhardinge
2006-10-08 10:36 ` Stas Sergeev
2006-10-08 10:39 ` Jesper Juhl
2006-10-08 13:22 ` Stas Sergeev
2006-10-06 22:26 ` Jesper Juhl
2006-10-04 19:30 ` [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps Stas Sergeev
2006-10-04 3:20 ` David Wagner
2006-10-04 3:17 ` David Wagner
2006-10-04 13:41 ` Jeff Dike
2006-10-04 18:02 ` Jesper Juhl
2006-10-04 19:48 ` Stas Sergeev
2006-09-27 19:16 ` [patch] remove MNT_NOEXEC check for PROT_EXEC MAP_PRIVATE mmaps Stas Sergeev
2006-09-27 20:05 ` Hugh Dickins
2006-09-28 4:33 ` Stas Sergeev
2006-09-28 16:42 ` Hugh Dickins
2006-09-29 1:41 ` David Wagner
2006-09-29 20:50 ` Arjan van de Ven
2006-09-29 16:54 ` Stas Sergeev
2006-09-24 19:59 ` [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps Alan Cox
2006-09-24 20:07 ` Stas Sergeev
2006-09-24 0:53 ` Arjan van de Ven
2006-09-25 17:17 ` Stas Sergeev
2006-09-25 17:43 ` Stas Sergeev
2006-09-25 20:12 ` David Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E4468D90-DABA-4622-983F-594B40EBE152@mac.com \
--to=mrmacman_g4@mac.com \
--cc=daw-usenet@taverner.cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®