I have a question and concern about Samhain.... I read where it is best to have /dev/kmem disabled(in general...not from Samhain)so there can be no runtime kernel modifications. Samhain uses it's own module called samhain_kmem.ko which generates a file /proc/kmem since samhain relies on the information provided from kmem for its kernel integrity check. So, it's kind of a contradiction....in one aspect the /dev/kmem is there for exploits. But on the other Samhain should be able to detect any kernel integrity of any exploits. I'm not sure which one is a better/safer route...not have /dev/kmem, do without Samhains kernel integrity checks, and significantly lower possible kernel exploits; or have /dev/kmem open and hope Samhain will always come through if there is an kernel exploit.

Also, Samhain's /dev/kmem data is extracted through it's own module samhain_kmem.ko. Just the fact that this is a module makes it a security vulunability since it is a module and not built into the kernel, correct?

No one ever made a more secure system by bolting more code on top.

1 members found this post helpful.

Ineresting theory....

Would SELinux be considered bolting more code on top?

Security vulnerabilities start off as innocent bugs, but with the right conditions they become security issues.

Is {SELinux,Samhain,grsecurity,etc...} completely bug-free? Not likely. If they add 10 bugs, what are the chances that one bug exists in the right environment for it to become a security vulnerability? (And that's being conservative, I've seen estimates more along the lines of 1 bug per 50 lines of code).

I'm not going to tell you not to run some block of code...in the end it's your machine, so you're the one that has to research it and figure it all out for yourself. Research /dev/kmem to see what conditions have to exist to exploit the system, and see if your environment matches.

Good example: A few years ago OpenBSD had an mbuf pointer bug that was shown to be remotely exploitable. The bug required MAC address manipulation and IPv6. The simplest solution, then, while waiting for the vendor to fix the bug permanently, was to configure the firewall to drop all IPv6 traffic (I didn't use it at the time anyways). Yeah, it's a remotely exploitable bug, but my system isn't vulnerable (and if they have permissions to change pf rules, the machine is already compromised).

Here's another good example: grsecurity Linux kernel add-on vulnerability (with /dev/kmem). That link is to an old vulnerability, yes...but it's an example of "security" code lessening the security of the system.

Edit - not to discredit the authors of grsecurity, I used grsecurity for years back when Gentoo and HLFS were my main OS's. This is just an example.

While "No one ever made a more secure system by bolting more code on top" offers an intriguing starting point for discussing lots of things it IMHO should not be necessary here to explain why one would want (or not want) /dev/kmem support. Building Linux kernels /dev/kmem has been a Kconfig option for some time and its help text states why: "/dev/kmem is VERY rarely used, and when used, it's generally for no good (rootkits tend to be the most common users)" (:Silvio Cesare papers, old SuckIT rootkit). Fedora, RHEL and Centos have supplied users with kernels without /dev/kmem support for about 6+ years now without any known problems or legit users of /dev/kmem.

Security being a continuous process and benefiting from a multi-layered approach, wrt samhain_kmem.ko yes-or-no, I'd say that question should best be answered by looking at what one defends and how one defends assets. For one, while there have been rootkits that do no longer require /dev/kmem access (: Phalanx) and no remote access of /dev/kmem is possible anyway, 0) the amount of root compromises in combination with rootkits being dropped has been dwindling consistently since easier avenues for malicious activity have been available (for years now), 1) malicious activity often is preceded by reconnaissance and failed attempts so having early warning detection really pays off but more than that does 2) investing in standard hardening practices as seem common sense and are promoted by SANS, CIS and say OWASP. You could conclude from this all and the official reasons given for removal that re-enabling /dev/kmem is disproportional given its risk and otherwise just one small aspect of what system security entails.