Re: [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease ofattacking

From: Ingo Molnar
Date: Thu Nov 18 2010 - 02:32:20 EST



Putting aside the kallsyms patch (which is a tiny part of a fuller solution), i'd
like to reply to this particular point:

* Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote:

> (2) Most of the arguments about introducing "uncertainty" into the
> hacking process are specious as well. [...]

It is only specious if you ignore the arguments i made in the previous
discussion. One argument i made was:

Future trends are also clear: eventually, as more and more of our lives
are lived on the network, home boxes are becoming more and more valuable.
So i think concentrating on the psychology of the skilled attacker would
not be unwise. YMMV.

> [...] If a kernel bug is truly a
> "workable" vulnerability then 99%+ of the attempts to exploit it would
> be completely automated virii and computer worms that don't really
> care what happens if they fail to compromise the system. Take a look
> at the vast collection of sample code we have in the form of Windows
> virii/trojans/worms/malware/etc; care to guess what portion of those
> programs authors would shed a tear if their exploit horribly crashed
> or generated vast amounts of audit spam for 70% of the computers it
> executed on?

( You'd be a fool to think that even windows malware authors do not care
whether they crash the target box. You do not get a botnet of 10 million PCs if
you crash 99% of them. There is an analogous concept for this in biology: if a
biological virus is _too_ deadly, it will never become a pandemic - because it has
no time/chance to spread, they are 'detected' and 'defended against'. Virii like
Ebola never spread widely, because they kill all their hosts. )

More importantly, look forward and take a look at the really intelligent attacks,
which are used against high-value targets with good defenses. Those real examples
give us a glimpse into future techniques, even if you do not accept my arguments
that come to a similar conclusion. Those attacks are all about avoiding detection.

Thanks,

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/