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

    Sytse Wielinga wrote:
    > On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
    >>That being said, you should also consider (unless somebody forgot to
    >>tell me something) that it takes two source trees to make a split-out
    >>patch. The author also has to chew down everything but the feature he
    >>wants to split out. I could probably log 10,000 man-hours splitting up
    >>GrSecurity. :)
    > I'd try out Andrew's patch scripts if I were you. If you're making a patch to
    > the kernel, you'd best keep it in separate patches from the beginning, and
    > that's exactly what those scripts are very useful for.
    >>>It's also a lot easier to find the (inevitable) bugs. Either you already
    >>>have a clue ("try reverting that one patch") or you can do things like
    >>>binary searching. The bugs introduced a patch often have very little to do
    >>>with the thing a patch fixes - exactly because the patch _fixes_
    >>>something, it's been tested with that particular problem, and the new
    >>>problem it introduces is usually orthogonal.
    >>true. Very very true.
    >>With things like Gr, there's like a million features. Normally the
    >>first step I take is "Disable it all". If it still breaks, THEN THERE'S
    >>A PROBLEM. If it works, then the binary searching begins.
    > So how do you think you would do a binary search within big patches, if it
    > would take you 10,000 man-hours to split up the patch? Disabling a lot of
    > small patches is easy, disabling a part of a big one takes a lot more work.

    'make menuconfig' is not a lot more work wtf

    [*] Grsecurity
    Security Level (Custom) --->
    Address Space Protection --->
    Role Based Access Control Options --->
    Filesystem Protections --->
    Kernel Auditing --->
    Executable Protections --->
    Network Protections --->
    Sysctl support --->
    Logging Options --->

    ?? Address Space Protection ??
    [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
    [ ] Disable privileged I/O
    [*] Remove addresses from /proc/<pid>/[maps|stat]
    [*] Deter exploit bruteforcing
    [*] Hide kernel symbols

    Need I continue? There's some 30 or 40 more options I could show. If
    you can't use your enter, left, right, up, y, n, and ? keys, you're
    crippled and won't be able to patch and unpatch crap either.

    >>>Which is why lots of small patches usually have _different_ bug behaviour
    >>>than the patch they fix. To go back to the A+B fix: the bug they fix may
    >>>be fixed only by the _combination_ of the patch, but the bug they cause is
    >>>often an artifact of _one_ of the patches.
    >>Wasn't talking about bugfixes, see above.
    > Oh, so you're saying that security fixes don't cause bugs? Great world you live
    > in, then...

    I didn't say that. I said I wasn't talking about bugfix patches. I
    wasn't talking about "mremap(0,0) gives you root," I was talking about
    "preventing following links under X conditions breaks nothing legitimate
    but deadstops /tmp races" or "properly setting CPU protections for
    PROT_EXEC stops code injection" or "ASLR stops ret2libc attacks."

    If you people ever bothered to read what I say, you wouldn't continually
    say stupid shit like <me> You get milk from cows <you> wtf idiot
    chocolate milk doens't come from chocolate cows

    >>>IOW, splitting the patches up makes them
    >>> - easier to merge
    >>> - easier to verify
    >>> - easier to debug
    >>>and combining them has _zero_ advantages (whatever bug the combined patch
    >>>fix _will_ be fixed by the series of individual patches too - even if the
    >>>splitting was buggy in some respect, you are pretty much guaranteed of
    >>>this, since the bug you were trying to fix is the _one_ thing you are
    >>>really testing for).
    >>Lots of work to split up a patch though.
    > See above.
    > Sytse

    - --
    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.027 / U:37.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site