From owner-freebsd-hackers Fri May 29 17:12:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06549 for freebsd-hackers-outgoing; Fri, 29 May 1998 17:12:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06523 for ; Fri, 29 May 1998 17:12:22 -0700 (PDT) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id CAA28498 for ; Sat, 30 May 1998 02:15:42 +0200 (CEST) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Sat, 30 May 1998 02:15:42 +0200 (CEST) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: freebsd-hackers@FreeBSD.ORG Subject: Signed executables, safe delete etc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi hackers, Recently I was thinking about various security-related issues, and came up with this idea (I'm sure nothing new at all). 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. This checking could go even earlier, that is in the bootblocks (I know - there is not single byte left there...), which could require user to enter a password in order to load the kernel (possibly decrypting previously encrypted part of freebsd partition). As for the signed binaries: this could be also a good way to ensure of the creator, owner etc of the binary, even with his email address and PGP key... :-) (ok, maybe I'v gone too far). I'm sure there are many difficult issues to resolve in this idea (such as: how to manage the keys). You can wonder what all this is for: it helps to ensure that no element of the system has been changed without you knowing it. It could be performed during startup of the system, and/or just before executing each binary (as far as I understand it, ELF allows to put pretty arbitrary sections into the binary). Moreover, this helps to ensure that the system won't boot without proper authorization, and even if someone steals it, it could refuse to give in (this would require encrypting the disk contents, of course - that's why I said about bootblocks...). 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. So, my question is: is this something worth pursuing? Has anyone seen something similar? etc, etc... Andrzej Bialecki --------------------+--------------------------------------------------------- abial@nask.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. --------------------+--------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message