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



Valdis.Kletnieks@vt.edu wrote:
> On Wed, 26 Jan 2005 14:31:00 EST, John Richard Moser said:
>
>
>>[*] 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.
>
>
> Just because I can use my arrow keys doesn't mean I can find which part of
> a 250,000 line patch broke something.
>

I can.

Read Kconfig. Find the CONFIG_* for the option. Find what that
disables in the code. Get to work.

> If it's done as 30 or 40 patches, each of which implements ONE OPTION, then
> it's pretty easy to play binary search to find what broke something.
>

Yes and those patches would implement what's inside #ifdef CONFIG_*'s,
so if turning an option off fixes something, it's fairly equivalent.
I'll let it slide that those patches would likley make "some" changes
that aren't in #ifdef blocks, making it a bit harder to track down,
since those changes can also cause breakage themselves and be even
tougher to track down (though maybe not, just read the patch for
non-blocked-off stuff in some cases).

> And don't give me "it doesn't break anything" - in the past, I've fed at least
> 2 bug fixes on things I found broken back to the grsecurity crew (one was a
> borkage in the process-ID-randomization code, another was a bad parenthesis
> matching breaking the intent of an 'if' in one of the filesystem protection
> checks (symlink or fifo or something like that).

Hmm? I found the PID rand breakage in 2.6.7's gr to be quite annoying
and disabled it. It took me all of 2 minutes to determine that PID
randomization was causing the breakage-- as I enabled it during boot
with an init script, the machine oopsed several times and then panic'd. :)

Heh, divide that 2 minutes by the thousands of people who look at the
code, and you find bugs before they're created :D (j/k)

- --
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/dbhDd4aOud5P8RAokYAJ9oukytYsqBhz71RtzpC4o7K9od1QCfTRou
ln0qF42yrB6+gi1Kt4YXudY=
=75yE
-----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    [W:0.221 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site