From owner-freebsd-hackers Sun May 31 02:35:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA27824 for freebsd-hackers-outgoing; Sun, 31 May 1998 02:35:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA27801 for ; Sun, 31 May 1998 02:35:24 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id CAA16757; Sun, 31 May 1998 02:35:20 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd016747; Sun May 31 02:35:11 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id CAA19826; Sun, 31 May 1998 02:34:54 -0700 (MST) From: Terry Lambert Message-Id: <199805310934.CAA19826@usr04.primenet.com> Subject: Re: Signed executables, safe delete etc. To: abial@nask.pl (Andrzej Bialecki) Date: Sun, 31 May 1998 09:34:54 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at May 30, 98 02:15:42 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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...). VMS will not mark an executable as executable unless the VMS linker is the program that created the file. In general, the VMS mechanism prevents programs without SYSPRIV from generating programs that can be loaded as executable. The mechanism prevents the common case in BSD-land of LISP and other binaries that extend the data space of executables with code. Typically, this is a bad trade-off, favoring security over usability. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message