>How can you rely only on an authentication method as a root intruder
>could obtain private keys by reading kernel space/kernel binary/module
>binary or even could overwrite signatures base with his own module
>signature, even if it is in kernel space ?
While it is desirable to harden the kernel against root attack, I am
more concerned about user level abuse. Schemes that lock down
the system against user level code also have their place, such
as webservers where CGI code is forbidden access to the network or
system files. My concern is for a desktop system, with one or more users
running code, doing email, browsing and generally getting on with life.
Some of the code they run has a legitimate reason to access the network
or system files - IRC, email, automatic updates etc. - so that
locking the system down is not really viable. Giving programs
capabilities would help somewhat - there is probably no good reason for
a screensaver to access /dev/video or the network - but a program with
legitimate need to access resources, such as a network game or
conferencing tool, might be infected with malevolent code. My suggestion
was for a mechanism in the kernel to authenticate binaries before they are
executed, akin to using GPG to authenticate RPM packages before installing
them, which would offer some protection against tampering with binaries
in an archive or obtained via NFS etc., and also against some rootkit
substitutions.
I suppose that a policy of requiring all software be installed
via authenticated RPM and that the installed binaries be regularly checked
against the RPM database would go some way to addressing this (although
this is getting a bit off-topic for the kernel). I confess, though, that
I'm not sure whether a chain of authentication can be easily verified from
the GPG signature on the package through the MD5 checksum in the database
to the binary itself.
Andrew Daviel
-
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/