linux-kernel - Re: [patch] honour MNT

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:	Sat, 7 Oct 2006 19:36:49 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: [patch] honour MNT_NOEXEC for access()

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.
-
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/