linux-kernel - Re: [patch] remove MNT_NOEXEC check for PROT_EXEC MAP

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: <451D4FE1.5060106@aknet.ru>
Date:	Fri, 29 Sep 2006 20:54:57 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@...hat.com>, Valdis.Kletnieks@...edu,
	Arjan van de Ven <arjan@...radead.org>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC MAP_PRIVATE mmaps

Hi.

Hugh Dickins wrote:
> The idea that loader
> should parse library pathname and /proc/mounts output, and thereby
> enforce "noexec" by itself, rather than relying on the kernel's
> mmap implementation to enforce it?
No. Yes, I agree with you that making the user-space app
to enforce the kernel restrictions is a silly solution.

Today I tried the following instead:
With the trivial 3-lines patch I made the loader to
be opened with fsuid=0. (as soon as opened, fsuid
returns back to original value).
That allowed me to control the use of ld.so with chmod.
Since, as I suppose, the users should not run the ld.so
directly, the "chmod 'go-x' ld.so" looks good. It looks
like that approach eliminates the noexec problem completely,
gives you a convinient and natural way to control the things
and costs only a 3 lines of code.
Or is it just another silly idea, or does it open a security hole?

> But again and again I have to point out, just
> because "noexec" has proved inconvenient to you here
Unfortunately, the distributors were caught too.

> There might be a loader which specifically seeks to avoid the
> mmap check, by mmapping without PROT_EXEC then mprotecting with
> PROT_EXEC.  Whether that's an argument for or against now adding
> the test to mprotect depends on your standpoint.
That actually made a lot of sense to me. You were continuously
pointing me to the real root of the problem (ld.so), but I was
distracted by the security claims of other's and thought the
security was the primary goal of these checks. If you think there
should be an official way of bypassing these checks, then I now
can clearly see where you are coming from. Be these really a
security checks, there would be no official way of bypassing them,
so they are obviously not. Now I completely agree that mprotect
should not be affected.
I actually seen a discussion about using an mprotect for the
programs that are currently break on debian, but the upstream
maintainer was worried that one day the mprotect may be restricted
too. Now I think he can change his mind, so at least for that,
this whole discussion was not useless. :)

> But I think I've already said all I have to say on this.
I understand, thanks anyway. As I said, you were the only one
trying to direct the discussion to the right place, sorry for
not seeing this for so long...

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