Re: [patch] Add basic sanity checks to the syscall execution patch

[Ingo Molnar]

* pageexec@xxxxxxxxxxx <pageexec@xxxxxxxxxxx> wrote:

> On 5 Sep 2008 at 18:52, Ingo Molnar wrote:
> 
> > * pageexec@xxxxxxxxxxx <pageexec@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/