Messages in this thread | | | Date | Mon, 6 Dec 1999 01:47:45 -0800 (PST) | From | Andrew Daviel <> | Subject | Re: malware defense |
| |
I had a few random thoughts on the subject, probably unworkable..
- 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/
| |