From owner-freebsd-hackers Mon Jun 1 03:53:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA13087 for freebsd-hackers-outgoing; Mon, 1 Jun 1998 03:53:14 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (QAkzALTCn5Rg+988QoZ4OXjZ1QH2yzq+@heron.doc.ic.ac.uk [146.169.46.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA13081 for ; Mon, 1 Jun 1998 03:53:07 -0700 (PDT) (envelope-from njs3@doc.ic.ac.uk) Received: from oak66.doc.ic.ac.uk [146.169.33.66] ([Mk086wlRXYQU5FF1wfBzWJQU8JxZbCYN]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0ygSCj-0000Ln-00; Mon, 1 Jun 1998 11:52:37 +0100 Received: from njs3 by oak66.doc.ic.ac.uk with local (Exim 1.62 #3) id 0ygSCi-0006lg-00; Mon, 1 Jun 1998 11:52:36 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Mon, 1 Jun 1998 11:52:36 +0100 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Andrzej Bialecki , Joe McGuckin Subject: Re: Signed executables, safe delete etc. Cc: freebsd-hackers@FreeBSD.ORG Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, 31 May 1998, Joe McGuckin wrote: > Yes, that's the situation I'm thinking about. As it was suggested to me by > Niall Smart, we already have something called securelevel. but this > protects only already existing binaries (and not new ones, possibly > exploiting e.g. kernel bugs) I'm not sure what you mean here, securelevels are intended to prevent binaries from being modified by anyone (among other things). You can set the immutable flags for any new binaries you compile. > and only on running system. To be more > precise: I know that when securelevel=2 or something, all the binaries > with immutable and append-only flags cannot be changed. But this doesn't > prevent executing user's own program (possibly in order to get root > shell). The huge majority of exploits can be written in shell script, so I doubt this will help much. For example, the vast majority of buffer overflows can simply be exploited using: suidprog -f `cat shellcode.bin` > What I thought was two separate ideas: > * the system would refuse to execute non-signed binary This is not useful, see my earlier post. Anyway, an easier way to do this would be to only allow the superuser to chmod +x an executable. > * the system would even refuse to boot and to load the kernel without > appropriate authentication. This would require cooperation from filesystem > (like encrypting parts of it, say superblocks) so that attacker couldn't > get the disk to other machine and mount it there. This is a good idea, though I would encrypt the whole disk. I have been thinking about this before and I think the best way to store the key to unlock the filesystem would be on a floppy disk, using stenography to embed it in a picture of Pamela Anderson or something. Anyway, I need to take those anti-paranoia pills now. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message