Re: [patch] remove MNT_NOEXEC check for PROT_EXEC MAP_PRIVATE mmaps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux