lkml.org 
[lkml]   [2005]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: thoughts on kernel security issues
-----BEGIN PGP SIGNED MESSAGE-----
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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB9+/zhDd4aOud5P8RAsZzAJ4rUryqsKc1OcfT4Nwc1m/lJtePPwCfXMWx
fEoc1nSxOfEzjJNZRDx6qYQ=
=NYJe
-----END PGP SIGNATURE-----
-
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: 2005-03-22 14:09    [from the cache]
©2003-2011 Jasper Spaans