- If binaries were signed with public key crypto, the kernel could
keep a list of authorized keys. To run your own code, sign it
yourself (preferably on a "secure" airgapped machine ...)
The procesing overhead to check keys might be crippling, though,
if done at every invocation.
- A MD5 daemon could be made part of a watchdog daemon. If it is killed,
the machine reboots (and hopefully comes up firewalled until
integrity verified). Still have to figure out how to stop said
daemon being killed and replaced with a double before the
watchdog has a chance to trip.
- Critical code could be randomized by re-ordering instructions
and inserting NOPs (like, I think, polymorphic viruses). Then
targeting a running binary becomes a bit more tricky than
just building the same version and mapping the data structures.
Douglas Kilpatrick mentioned LOMAC - I had a quick look.
Seems LOMAC uses a tainting-type model where data from an untrusted NIC
can taint a process causing it to be demoted to a lower access level.
Not sure how to use this and allow remote maintenence by root.
Also no protection of objects from objects at the same level, e.g.
one CGI script from another.
LOMAC documentation refers to a number of other projects, listed below
LOMAC
ftp://ftp.tislabs.com/pub/lomac
loadable module
Rule Set Based Access Control (RSBAC) for Linux
http://www.compuniverse.com/rsbac
kernel patch
Linux-Privs
ftp://ftp.lip6.fr/pub/linux/security/linux-privs
kernel patch
Generic Software Wrappers Toolkit - NAI
ftp://ftp.tislabs.com/pub/wrappers
restricitive conditions at present
Seems other people are working on this if only I'd known where
to look. I guess if malware gets to be a serious problem some of
these solutions will suddenly become mainstream.
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/