lkml.org 
[lkml]   [2006]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps
    Hi.

    Ulrich Drepper wrote:
    >> The one that goes to /dev/shm should allow PROT_EXEC, yet
    >> not allow executing the binaries with execve().
    > Why on earth would you want this? Previously you already acknowledged
    > that this kind of "protection" can be worked around by using ld.so
    > directly.
    I have not acknowledged this but rather was pointed out
    to that fact and to that the checks were supposed to solve
    this problem.
    I agree the problem does exist, but isn't it a user-space
    problem? Hugh Dickins points out that the failure of PROT_EXEC
    mmap is a quick way for ld.so to find out the fact that the
    partition is mounted with "noexec". But are there really no
    other ways? Maybe (just maybe, I am unaware about details) ld.so
    can look into /proc/mounts or similar and do the right thing
    itself?

    > Either all executable mapping is forbidden or none. No middle ground
    > can exist.
    Exactly. So why such a "middle-ground" solution is currently
    there? I can:
    1. mprotect() the existing mapping to PROT_EXEC and bypass the
    checks (but you can easily restrict that by patching mprotect()).
    2. Do the anonymous mmap with PROT_EXEC set, then simply read()
    the code there, then execute. This you *can not* restrict!

    On the other hand: such a checks hurts the properly-written
    code *only*, no malicious loaders can be affected. The properly-
    written code breaks because it uses MAP_SHARED mmaps - that's
    what you can restrict. The malicious loader will simply read
    the code into the area previously mmaped anonymuosly - it doesn't
    need MAP_SHARED. As you pointed out, such a malicious loader can
    probably be a script. So, by rejecting the file-backed mmaps with
    PROT_EXEC set, you hurt the good programs, while the bad ones are
    completely unaffected.
    Now, the breakage of the properly-written programs forces people
    to stop using "noexec" on /dev/shm-mounted tmpfs. As far as I
    understand, having the single writeable and executable mountpoint
    is almost as bad as having all of them. The attacker will now simply
    put his binary into /dev/shm.
    IMHO, allowing people to use "noexec" for /dev/shm and making ld.so
    to use other ways of finding the "noexecness" will solve the
    problem, at least to the much better state than currently.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-09-24 18:33    [W:0.028 / U:0.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site