Hi again Ralph,
On Mon, May 23, 2005 at 06:13:32PM +0100, Ralph Corderoy wrote:
My humble opinion is that you have much bigger problems if a malicious program has root priviledges in your system.
Sure, if a security "hole" is easy to plug, why not plug it, but there are many other security measures that can and should be used on production systems with important data that are effective for recovering from an attack of this kind as well as several others. (Redundant hardware and storage, with external backups.)
A scenario: I have daily backups, I carry out a post-mortem after detecting an intrusion, I'm happy to re-install from scratch and restore a known-safe backup, and fix the entry point of the cracker before exposing the machine to the network. But the hard drive is now for the bin because it's been locked.
I'm happy to take all those other precautions, but I'm trying to cut out one of the few things a malicious, remote, cracker could do that costs me hardware.
Right, no redundant storage, which probably wouldn't be susceptible to the problem anyway since the security commands only work with ATA and S-ATA drives.
I know I wouldn't care much about the ATA drive if I was prepared to deal with downtime and labor required for forensics and recovery in the above scenario.
Then, suddenly, the Linux kernel isn't so late in the boot process. Remember, LinuxBIOS doesn't care about legacy junk such as the MBR, it starts the payload immediately, as per compile-time configuration.
I agree if the Linux kernel is very early on, i.e. the BIOS stage, then it's good enough for the kernel to do it. I was talking about the OS once started by the bootloader.
With Linux as the payload, the OS is the bootloader. :)
But wouldn't that require a run-time option again because you'd want to avoid the freeze happening some times, and without flashing a new BIOS.
Right. And the option can't be accessible by root.
It's far easier and more portable to write the MBR than it is the BIOS. Given root access will sometimes be obtained I'd like to stop them being able to make my hard drive defunct; its data I've got backed up, offline. It's all a trade-off but it would seem that adding an ATA Freeze most of the time on start-up is a worthwhile one.
"more difficult and less portable" is not "secure" - I would argue quite the opposite; it's security by obscurity, and that's always a bad idea.
But sure, if you want to protect the BIOS from software run as root, use real ROM (not flash). And if you want to protect the ATA drive from being locked by root, have the software in ROM send a freeze command.
Question is, should LinuxBIOS really go about changing configuration and settings of the hardware beyond what is absolutely neccessary for the payload to function?
I'm not sure it should, I think it's better to put the freeze command in FILO or Linux or 9load or ADLO or whatever payload.
From a security point of view it doesn't matter since the LinuxBIOS
init code and payload are stored in the same place and if the payload can be changed the init code can be changed too.
//Peter