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]

Message-ID: <4522BCBF.2050508@aknet.ru>
Date:	Tue, 03 Oct 2006 23:40:47 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Hugh Dickins <hugh@...itas.com>, Valdis.Kletnieks@...edu
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

Hello.

Ulrich Drepper wrote:
> You really don't get it, do you.
Yes, sorry. :)

> The way ld.so works can be implemented
> in many other forms with other programs.
Having "noexec" (in its older form) on *every* user-writable
mount makes it harder for an attacker to run his own loaders,
so implementing it in other forms was useless in the past.

> With some time and energy you
> likely can write a perl or python script to do it.
This is solvable the same way too - "chmod 'o-x' perl"
and run the scripts via binfmt-misc (not sure if this is
really suitable though). You need a trivial kernel patch
to make that possible.

>> And allow an attacker to store his files on that partition,
>> and then execute them.
> They can do it anyway.
With having "noexec" (in its older form) on every user-writable
partition - how they can do it?

>> I have already proposed another solution for ld.so problem
>> 3 times.
> And for obvious reasons I ignored it.
Some explanation could do better, but oh well.

> noexec mounts the way _you_ want them are completely, utterly useless.
But I used them. And having them on _every_ user-writable
mounts at least used to give some results.

> nonexec mounts as they are today plus an upcoming mprotect patch give
As was pointed out by Hugh, such a patch is unlikely.

> fine grained control.
Control of what? The malicious loader will always work - it is
unaffected by both mmap and mprotect changes. So what you can
control is only how many apps you break.

> You have to use additional mechanism like SELinux
> to fill in all the holes but that's OK.
Yes, selinux is the only solution here.

> nonexec mounts give a great
> deal more of flexibility.
Any real-life examples of what problem does this solve?
(except of the already discussed partially-solved ld.so problem)

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