From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [patch] honour MNT_NOEXEC for access()
Date: Sat, 7 Oct 2006 19:36:49 +0000 (UTC) [thread overview]
Message-ID: <eg8vkh$u1m$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 4527FC8B.8010208@aknet.ru
Stas Sergeev wrote:
>Ulrich Drepper wrote:
>>> Now, as the access(X_OK) is fixed, would it be
>>> feasible for ld.so to start using it?
>> Just must be kidding. No access control can be reliably implemented at
>> userlevel. There is no point starting something as stupid as this.
>But in this case how can you ever solve the
>problem of ld.so executing the binaries for which
>the user does not have an exec permission?
By using the kernel's existing access control -- not trying to roll
your own access control at the user level. This is a standard recommendation
in the security world, and it is good advice.
For instance, in this case, this advice might mean that you just call
execve() and check whether it succeeded or failed, and let the kernel
do the access control check on whether the exec is permitted. That tends
to be more fool-proof (or at least fool-resistant) than the alternatives.
>Yes, the userspace apps usually should not enforce
>the kernel's access control, but ld.so seems to be
>the special case - it is a kernel helper after all,
>so it have to be carefull and check what it does.
Perhaps. But it seems to me that there would need to be a persuasive
argument before it makes sense to violate the general advice listed above.
next prev parent reply other threads:[~2006-10-07 19:36 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-23 10:30 [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps 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
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 [this message]
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='eg8vkh$u1m$1@taverner.cs.berkeley.edu' \
--to=daw@cs.berkeley.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.