Messages in this thread | | | Date | Fri, 5 Sep 2008 13:42:33 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Add basic sanity checks to the syscall execution patch |
| |
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > and that'd be because at the same time they patch the syscall table (remember, > > they already have to go to length to get around the read-only pages), they > > can't also patch this 'protection'? sounds really plausible, right :). > > > > [fixed hpa's address, .org bounces.] > > Sure, they can :-) > > It's just an idea I had on irc but I tend to agree that it wouldn't > have much effect in practice... regarding security, it will break some > existing rootkits ... until updated ones show up.
at which point we are left with a change that has no relevance to updated rootkits (they circumvent it just fine), while the kernel syscall entry path is left with 2 cycles (or more) overhead, forever.
Not a good deal.
We introduced the read-only syscall table because it has debugging and robustness advantages, with near zero cost. This change is not zero cost - it's ~1% of our null syscall latency. (which is ~100 nsecs, the cost of this check is ~1 nsec)
The other, more fundamental problem that nobody has mentioned so far is that the check returns -ENOSYS and thus makes rootkit attacks _more robust_ and hence more likely!
The far better solution would be to insert uncertainty into the picture: some sort of low-frequency watchdog [runs once a second or so] that tries to hide itself from the general kernel scope as much as possible, perhaps as ELF-PIC code at some randomized location, triggered by some frequently used and opaque kernel facility that an attacker can not afford to block or fully filter, and which would just check integrity periodically and with little cost.
When it finds a problem it immediately triggers a hard to block/filter vector of alert (which can be a silent alarm over the network or to the screen as well).
that method does not prevent rootkits in general (nothing can), but sure makes their life more risky in practice - and a guaranteed livelihood and risk reduction is what typical criminals are interested in primarily, not whether they can break into a particular house.
If we implement it then it should not be present in distro .config's, etc. - it should be as invisible as possible - perhaps only be part of the kernel image .init.data section in some unremarkably generic manner.
[ It would be nice to have a 'randomize instruction scheduling' option for gcc, to make automated attacks that recognize specific instruction patterns less reliable. ]
A good benchmark for such a silent alarm facility would be whether an experienced kernel developer could reliably tell it via a kgdb session and full access to memory and system symbols that such a silent alarm is running on a box. If he cannot do it reliably then there's probably no good way for an attacker either.
And of course all the other layers of security play a bigger role: an attacker should not get to (native) kernel level access to begin with.
Ingo
| |