Messages in this thread | | | Date | Sat, 6 Sep 2008 17:42:15 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Add basic sanity checks to the syscall execution patch |
| |
* pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> On 5 Sep 2008 at 18:52, Ingo Molnar wrote: > > > * 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?
it's minimal and easy. It really works to operate on the source code - this 'open source' thing ;-) We just still tend to think in terms of binary software practices that have been established in the past few decades.
> > 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.
not a problem really, it is rather small compared to all the stuff that is in a typical disto install. I like the fundamental message as well: "If you want to be more secure, you've got to have the source code, and you've got to be able to build it."
> > > [...] 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.
it's not an unsolvable problem. The debug info can be on a separate box, encrypted, etc. etc - depending on your level of paranoia. The need to debug kernel crashes is a relatively rare event - especially on a box that has such high security constraints, fortunately :-)
> > 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? [...]
why no module support? Once the system has booted up all necessary modules are loaded and the ability to load new ones is locked down as well. This also makes it harder to inject rootkits btw. (combined with signed modules - patches exist for that)
> [...] what about kprobes and/or whatever else that generates code at > runtime?
you dont need that in general on a perimeter box. If you need it, you open that locked box with the debug info and make the system more patchable/debuggable - at the risk of exposing same information to attackers (were they gain the same level of access).
> > 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)?
are you now talking about the randomized kernel image? The whole point why i proposed it was to hide the checking functionality in it, not to make it harder for the attacker to place the rootkit.
Once the identity of the checking code is randomized reasonably, we can assume it will run every now and then, and would expose any modifications of 'unused' kernel functions. (which the attacker would have to filter out of the randomized image to begin with)
> 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?
best would be hardware support for mark-read-only-permanently, but once the checker functionality is reasonably randomized, its data structure can be randomized as well.
> > 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.
yes, hashes. The point would be to make the true characteristics of the checker a random, per system property. True, it has many disadvantages such as the inevitable slowdown from a randomized kernel image, the restrictions on debuggability, etc. - but it can serve its purpose if someone is willing to pay that price.
best (and most practical) tactics would still be to allow the kernel to be locked down, in terms of not allowing new (non-authorized) kernel code to be executed: signed modules and properly locked down debug APIs, so that the only vector of code insertion is a not yet fixed kernel space security hole.
Ingo
| |