>> 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.
>> 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.
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?
>> Sharing devices over a network (not justs Disks with NBD, serial
ports,
>> sound cards, USB devices, etc)
>> (Why buy multiple devices when I can share!)
>Sounds like a user space problem. See vmware for an example.
I guess I thought this more as a kernel level feature, by emulating /dev
devices so they appear as real devices to the higher kernel functions.
Wouldn't it be faster to implement this in the kernel compared to userland?
>> TCP intercept -- verifies TCP connections before passing on the
>> connection to userland. To prevent DoS and Spoofed attacks.
>Already implemented: SO_ATTACH_FILTER et.al.
>Even with the best filters you won't prevent DoS and spoofing though.
Right, but this feature reduces the effects of DoS/Spoofed Attacks.
--- 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