From owner-freebsd-security Tue Dec 22 09:17:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18742 for freebsd-security-outgoing; Tue, 22 Dec 1998 09:17:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18737 for ; Tue, 22 Dec 1998 09:17:02 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA15591; Tue, 22 Dec 1998 12:16:14 -0500 (EST) Date: Tue, 22 Dec 1998 12:16:13 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Dag-Erling Smorgrav cc: cjclark@home.com, Janos Mohacsi , security@FreeBSD.ORG Subject: Re: preventing single user login w/o password In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 21 Dec 1998, Dag-Erling Smorgrav wrote: > "Crist J. Clark" writes: > > Janos Mohacsi wrote, > > > How can I prevent booting FreeBSD into the single user mode without > > > supplying either root or maybe different password? > > Here's the simple answer, but you might not like it, > > > > Control physical access to the machine. > > > > "There is no security without physical security." > > Well, you can translate physical access to the computer into physical > access to a more manageable item, such as a Java ring, if you use some > kind of hardware device which strongly encrypts your disks and keep > the encryption key on the Java ring. The idea is that you can't boot > the computer without the ring, and you can't decrypt the contents of > the disk drive without it either (not within reasonable amounts of > time, anyway). I'm actually not sure this is a solution. If I have physical access to the machine, I can induce (via hardware or software) a mechanism to capture your key when or before you attach the key to the machine so that the decryption can occur. I think there is a fairly strong evidence that 'tamper-proof hardware' simply cannot exist, at least not economically, if not at all. If your key was required to perform the disk-decryption operations, presumably that is a step in the right direction, but if it just transfers the key, I come in and set something up to intercept the key when you arrive to boot the machine. It's sort of like the kerberos database master key--if anyone cares, they can get it trivially. If it is before kerberos has started, look for a stash file or trojan the terminal driver; if it is after, attach a debugger to the kerberos process, if it uses the key, it must have it in a recoverable form. So why bother? :) Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message