In <000101bfb84f$f96a6590$1f0201c0@lw100> Ron Van Dam (rvandam@liwave.com) wrote:
>>> Security integrity checking ( log if the system was booted with a
>>> different kernel, log when kernel modules are loaded)
>>User space/bootloader/external hardware problem (how can a kernel that has
>>been tampered with audit itself? -- to be really sure you need external
>>tamperproof hardware)
> Well my thought was if you are running syslog on another box you would have
> somewhat of a temperproof
> system. For instance an intruder compromises root. loads a kernel module to
> hide his/her activities. If modules are logged there's one more piece of
> evidence that the system has been compromised. Right now (under 2.2 kernels)
> I do not see any logs when I load (or remove) modules.
It was discussed zillion times already. It was just called "non-executable
stack". "One more layer of toilet paper" (instead of reliable lock) is NOT
acceptable in mainstream kernel. It's security via obscurity. It WORKS.
Really. But ONLY as long as it's not in mainstream kernel. Once such feature
is in mainstream kernel it's in VERY short time added to "automagic cracker
toolset" and then we have only bloat in kernel and no additional security
at all. So implement it as local patch if you wish -- it'll help you more
this way.
>>> Enable Kernel Module signatures so any foriegn kernel modules will be
>>> refused. (to avoid Kernel Module hacking).
>>Not practical (unless you break the X server by disallowing /dev/kmem
>>and ioports access)
> I thinking about including a unique ID in the kernel that is generated
> during compile time. All modules that are built must reference this ID. If I
> transfer a kernel module binary from a different system it would be refused.
> In order for me to build a new kernel module, I would have to build that
> module under my kernel. If the systems doesn't have compiler tools, new
> modules can't be easily installed.
Compiler tools can be easily transferred and even magic number can be moved
to aleady cracked host (it can be easier). The only bullet-proof way here is
PGP-like signatures and I doubt we want THAT in kernel.
> I don't understand how this would be an issue with X, except for possible
> with the DRI support with pre-compiled kernel modules. Yes, this would mean
> if you want to run X with DRI you would have to compile them. Why would you
> need to disallow /dev/kmem and ioports to support this feature?
Huh ? Are you joking or what ? If you can write to /dev/kmem or have access
to ioports then you can easily (not trivial, but easily enough) disable all
checks in kernel and THEN load module.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:21 EST