[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080905114233.GA27878@elte.hu>
Date: Fri, 5 Sep 2008 13:42:33 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: pageexec@...email.hu, Andi Kleen <andi@...stfloor.org>,
Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org, tglx@...x.de, hpa@...or.com
Subject: Re: [patch] Add basic sanity checks to the syscall execution patch
* Benjamin Herrenschmidt <benh@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists