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] [day] [month] [year] [list]

Message-ID: <45290143.80808@aknet.ru>
Date:	Sun, 08 Oct 2006 17:46:43 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Ulrich Drepper <drepper@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jakub Jelinek <jakub@...hat.com>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hugh@...itas.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [patch] honour MNT_NOEXEC for access()

Hello.

Arjan van de Ven wrote:
> But when invoked manually.. there is even LESS special about it... it
> could be ANY file on the system. And it's no different from any other
> file in /bin, /usr/bin etc etc
I agree with that completely, but it was not me
who started adding the ld.so-specific tricks to
the kernel, making it special.
The assumptions of the current mmap check are:
1. The program does mmap with PROT_EXEC, not mmap/mprotect
(it was explicitly pointed out that this is unlikely to change).
2. The program does the file-backed mmap, not the anon
mmap then read.
That suits ld.so very well because it happened to work that
way, but it is not very usefull for pretty much anything else
(unless someone can show the real-life examples).
So this is what makes ld.so special. Right now it checks
exec/noexec by trying mmap(PROT_EXEC) and see if that fails.
But there can be other ways to check that, including the ones
that will not break the other progs/configurations.
And I don't see any harm in having a way for the program
to explicitly say whether it wants an exec perm or not.
(access() suits exactly for that, but it is racey)

>> Otherwise, please tell me, how can you solve the problem
>> of ld.so started directly, can execute the files you do
>> not have an exec permission for?
> denying PROT_EXEC of non-"x" files does (somewhat).
But you can't do that - lets be realistic. Also I wonder
whether it will violate the posix specs or not.

> It's never fool
> proof obviously, as long as you need to allow jits.
Certainly.

>> Then ld.so can just use that to solve all those permission
>> problems.
> this is just entirely a wrong assumption; one based on the assumption
> that ld.so is something special, that it isn't.
Yes, that assumption is wrong, but it was not me who
invented it. I only want to move the ld.so-specific
stuff to ld.so itself, nothing more.

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