Re: [patch] remove MNT_NOEXEC check for PROT_EXEC MAP_PRIVATE mmaps
From: Stas Sergeev
Date: Fri Sep 29 2006 - 12:53:35 EST
Hugh Dickins wrote:
The idea that loaderNo. Yes, I agree with you that making the user-space app
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?
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, justUnfortunately, the distributors were caught too.
because "noexec" has proved inconvenient to you here
There might be a loader which specifically seeks to avoid theThat actually made a lot of sense to me. You were continuously
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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/