Date: Sat, 30 May 1998 10:32:43 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) To: Andrzej Bialecki <abial@nask.pl>, freebsd-hackers@FreeBSD.ORG Subject: Re: Signed executables, safe delete etc. Message-ID: <E0yfi0J-0004ev-00@oak66.doc.ic.ac.uk> In-Reply-To: Andrzej Bialecki <abial@nask.pl> "Signed executables, safe delete etc." (May 30, 2:15am)
next in thread | previous in thread | raw e-mail | index | archive | help
On May 30, 2:15am, Andrzej Bialecki wrote: } Subject: Signed executables, safe delete etc. > > What I imagine is e.g. to have kernel and/or init(8) check it's own binary > file against a checksum of some kind (preferably MD5 or SHA) stored > somewhere. If the checksumming fails (i.e. the kernel or init have been > tampered with) it refuses to go on. If an attacker can tamper with the kernel or init then he can simply remove this code which performs this check, or make it a nop. Use securelevels to protect system binaries from modification. Also check out tripwire which has the kind of functionality you talk about and can be useful when setting immutable flags on a particular file is impractical. (e.g everyones .login) > The second idea is to add new flag and functionality to FFS: purge on > delete. If this flag is set, kernel would wipe out the contents of the > file which is being deleted, using special patterns (3-7 times). This > would ensure that if you delete the sensitive data, they are really > deleted and unrecoverable. Yes, this would be useful to certain people. A encryption layer on top of the read/write interface to disks would also be nice, people have worked on this, but I don't have the URL handy. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0yfi0J-0004ev-00>