kprobes on by default in 2.6.20.1 kernel.org kernels

[Frank Ch. Eigler]

Nathan DeBardeleben <ndebard@lanl.gov> writes:

> [...]  machines.  Honestly I'd like to be able to add to my
> repertoire a good argument to allow kprobes on by default on these
> machines but when you're dealing with security plans and documents
> and whatnot a new technology like this is easily deemed scary,
> unknown, and just relegated to the "security risk" column.

Just as keeping module loading activated, /proc/*mem available, and
probably a dozen other facilities, calling kprobes a security risk
just takes an expediently simple view of the thing.  It must be
remembered that all of these exist because of the benefits they bring,
whether functional, administrative, operational - they tend to be
sufficiently useful to outweigh their hypothetical abuse potential.

In this way, kprobes is really no worse than the others.  If your
threat scenario involves software that actively hides itself, then you
have to lock many other things down.  If you worry about a lesser
complexity of attacks, then the various self-policing mechanisms
present (the __kprobe-marked non-probable sections, root access
required, systemtap's auditing printk at startup, ...) are probably
sufficient.

- FChE