[lkml]   [2005]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: thoughts on kernel security issues
    Hash: SHA1

    Ingo Molnar wrote:
    > * John Richard Moser <> wrote:
    >>Split-out portions of PaX (and of ES) don't make sense. [...]
    > which shows that you dont know the exec-shield patch at all, nor those
    > split-out portions. At which point it becomes pretty pointless to
    > discuss any technical details, dont you think?

    I'm shoddy on ES details, but I was more remarking on the overlapping
    functions between PaX and ES.

    >>PT_GNU_STACK annoys me :P I'm more interested in 1) PaX' full set of
    >>markings (-ps for NX, -m for mprotect(), r for randmmap, x for
    >>randexec), [...]
    >>I guess it works on Exec Shield, but it frightens me that I have to
    >>audit every library an executable uses for a PT_GNU_STACK marking to
    >>see if it has an executable stack.
    > here there are two misconceptions:
    > 1) you claim that the manual setting of markings is better than the
    > _automatic_ setting of markings in Fedora. Manual setting is a support
    > and maintainance nightmare, there can be false positives and false
    > negatives as well. Also, manual setting of markings assumes code review
    > or 'does this application break' type of feedback - neither is as
    > reliable as automatic detection done by the compiler.

    PaX has trampoline detection/emulation. I think the toolchain spits out
    libraries with -E when there's one. It's not inherited from libraries
    to the executable though; but a quick hack to trace down everything from
    `ldd` or `readelf` and grab the -E would do the same thing without
    giving a fully executable stack.

    > 2) you claim that you have to audit everything. You dont have to. It's
    > all automatic. _Fedora developers_ (not you) then check the markings and
    > reduce the number of executable stacks as much as possible.

    And a distribution maintainer could do the same with PaX. Once it's
    done it's fairly low maintenance. I know because I've done it myself.
    I can determine minimal pax markings on a given binary in about 15
    seconds in most cases.

    >>[...] ES' NX approximation fails if you relieve protections on a
    >>higher mapping-- which confuses me, isn't vsyscall() a high-address
    >>executable mapping, which would disable NX protection for the full
    >>address space?
    > another misconception. Read the patch and you'll see how it's solved.

    I've been told it maps vsyscall at a lower address, though didn't
    remember until after I hit send. Is this true?

    >>Aside from that, I just trust the PaX developer more. He's already
    >>got a more developed product; he's a security developer instead of a
    >>scheduler developer; and he reads CPU manuals for breakfast.
    > this is your choice, and i respect it. Please show the same amount of
    > respect for the choice of others as well, without badmouthing anything
    > just because their choice is different from yours.

    I respect you as a kernel developer as long as you're doing preemption
    and schedulers; but I honestly think PaX is the better technology, and I
    think it's important that the best security technology be in place. My
    concerns are only with real security, and in that respect I feel that if
    I didn't stand up and assert my understandings on the matter that people
    may hurt themselves. I can't put a slave collar on people and use force
    feedback to control their minds, but I don't have to keep quiet either.

    It doesn't much matter at this point. If everything goes well, PaX
    should show up in a fairly popular distribution soon, so we'll get to
    finally see something added that this conversation lacks: a genuine
    large-scale demonstration of the deployment of PaX. ES has that
    already; but until I can see the excellence and the failings of PaX
    deployed with a target on the average user as well, I can't make
    assessments about which deploys better in what cases and why.

    On a final note, isn't PaX the only technology trying to apply NX
    protections to kernel space? Granted, most kernel exploits aren't RCE;
    but it's still a basic protection that should be in place. Wouldn't it
    be embarassing to say one day that RCE is so rare we don't need to waste
    effort on kernel-level W/X separation, then the next day see an RCE
    exploit? :P (do it murphy, do it! >:P) This is just a generic
    observation; as I said, RCE in kernel is rare enough to not be a major
    selling point, but it's still a consideration.

    > Ingo
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > More majordomo info at
    > Please read the FAQ at

    - --
    All content of all messages exchanged herein are left in the
    Public Domain, unless otherwise explicitly stated.

    Version: GnuPG v1.4.0 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird -

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.026 / U:0.320 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site