lkml.org 
[lkml]   [2008]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-09-06 17:45    [W:0.093 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site