From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 3 16:19:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C85816A4CE for ; Sun, 3 Apr 2005 16:19:18 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7B3A43D58 for ; Sun, 3 Apr 2005 16:19:17 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j33GJQh3079168; Sun, 3 Apr 2005 09:19:27 -0700 (PDT) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j33GJJMJ079167; Sun, 3 Apr 2005 09:19:19 -0700 (PDT) (envelope-from www) Date: Sun, 3 Apr 2005 09:19:19 -0700 (PDT) Message-Id: <200504031619.j33GJJMJ079167@marlena.vvi.at> To: sos@DeepCore.dk From: "ALeine" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ATA security commands, bug in atacontrol X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2005 16:19:18 -0000 sos@DeepCore.dk wrote: > Right, I did see that article but I've not settled on how if at > all to deal with it. The by far most secure method would be to > have ATA issue the freeze command ASAP in the probe/attach code, > thats about one line of code :) > > At any rate atacontrol is not the place to put it if we want this > to up security... There are some people who would want to be able to issue ATA security {set,unlock,disable} password and other commands, but have no BIOS user interface to change any of the ATA security settings. This functionality clearly belongs in BIOS and issuing the ATA security freeze lock command automatically like you suggested would indeed protect the disk from unauthorized ATA security changes, but it would also make it impossible for users to use the ATA security features from FreeBSD. Perhaps there could be a kernel sysctl variable such as hw.ata.security.issue_freeze_lock_command_on_boot which would be set to 1 by default. Users who know what they are doing could still be able to override it by placing hw.ata.security.issue_freeze_lock_on_boot=0 into /boot/loader.conf. This override would then be honoured only in single user mode to prevent a simple reboot from rendering a disk unusable in case of system compromise. How does that sound to you? :-) The ATA security commands could then be added to atacontrol for those who need them and in any case I believe more detailed ATA security info should be reported by atacontrol. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net