On 5 Sep 2008 at 18:52, Ingo Molnar wrote:

quoted text
> * pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> 
> > > i think Linux is fundamentally different here as we have the source 
> > > code, and could apply the randomization technique i mentioned:
> > 
> > how's that supposed to work for the binary distros, i.e., the majority 
> > of end users? [...]
> 
> it takes less than 10 minutes to build a full kernel on recent hardware. 

provided the end user wants/needs to have the whole toolchain on his boxes
at all. how many really do?

quoted text
> Can be done in the background after install or so.

it's not only installation time (if you meant 'installing the box' itself),
but every time the kernel is updated, so the toolchain will be there forever.

quoted text
> > [...] and who would look at all the bugreports from such kernels?
> 
> yes, in this area debuggability is in straight conflict. Since we can 
> assume that both attacker and owner has about the same level of access 
> to the system, making the kernel less accessible to an attacker makes it 
> less accessible/debuggable to the owner as well.

in other words, it's a permanently unsolved problem ;). somehow i don't see
Red Hat selling RHEL for production boxes with the tag 'we do not debug crashes
here because we cannot' attached.

quoted text
> > > a successful attack that wants to disable the checks
> > 
> > why do you assume that an attacker wants to do that? it's equally 
> > possible, and there's even academic research on this in addition to 
> > the underground cracking scene, that one simply hides the 
> > modifications from the checker.
> > 
> > from marking your patched code as unreadable to executing it from a 
> > different place than what the checker checks, there're many ways to 
> > trick such checkers. as far as reality goes, it's never been game over 
> > ;).
> 
> well at least in the case of Linux we have a fairly good tally of what 
> kernel code is supposed to be executable at some given moment after 
> bootup, and can lock that list down permanently until the next reboot, 

so no module support? what about kprobes and/or whatever else that generates
code at runtime?

quoted text
> and give the list to the checker to verify every now and then?

so good-bye to large page support for kernel code? else there's likely
enough unused space left in the large pages for a rootkit to hide.

what if the rootkit finds unused pieces of actual code and replaces
that (bound to happen with those generic distro configs, especially
if you have to go with a non-modular kernel)?

last but not least, how would that 'lock that list down' work exactly?
what would prevent a rootkit from locating and modifying it as well?

quoted text
> Such a verification pass certainly wouldnt be cheap though: all kernel 
> pagetables have to be scanned and verified, plus all known code (a few 
> megabytes typically), and the key CPU data structures.

what would you verify on the code? it's obfuscated so you can't really
analyze it (else you've just solved the attacker's problem), all you can
do is probably compute hashes but then you'll have to take care of kernel
self-patching and also protecting the hashes somehow.

--
unsubscribe notice
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/