Date: Sun, 3 Apr 2005 09:19:19 -0700 (PDT) From: "ALeine" <aleine@austrosearch.net> To: sos@DeepCore.dk Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ATA security commands, bug in atacontrol Message-ID: <200504031619.j33GJJMJ079167@marlena.vvi.at>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504031619.j33GJJMJ079167>