Re: OpenBSD business model

From: Marcus Watts <mdw(at)umich.edu>
Date: Fri Feb 28 2003 - 12:56:48 EST

Peter Fairbrother <zenadsl6186@zen.co.uk> writes: ...
> To give a trivial example or two, boot a *nix box from bsd.rd, mount a drive
> - you can access anything on it. Anyone with a root password can access
> anything on the box (yes, there are OS's that don't have these properties).
...

Well, yes, there are. And there are problems with that approach.

There are two ways this is done:
(1) what Windows NT does. Sure, Windows NT won't mount it without

	the administrator's password.  But that's just smoke & mirrows;
	you can mount it under KNOPPIX just fine (though making changes gets
	more interesting...)

(2) encrypted filesystem. This gets complicated, but generally there are two ways to do this: have each file have its own encrypting key, or use one key to encrypt the entire disk. In both cases, you'd have that key as a master key to generate subkeys to encrypt the actual data, but this is just an implementation detail; the security depends on how you protect the master key, the sub-keys are just part of a special sort of variable block length encryption scheme. Things get more icky if you consider the case that several users might want to share access to data, and how do you handle unattended system cold restarts?

One class of problem you run into with either is "maintenance". With windows, how do you remove a virus that has infected half the user files on the machine? With the encrypted filesystem, how do you handle backups? With either, how do you recover partial data from crashes? How do you repair damage done by an inept system administrator who removes half the file from /etc?

The security also becomes interesting -- with your encrypting filesystem, especially with the encrypted files, you have a monumental key management problem. You have to guarantee that when the machine is turned off, no keys are accessible, when the machine is turned on, users supply sufficient key information to generate strong secrets, and while the machine is on, people can't steal each other's secret keys. These are hard problems, which is why encrypted filesystems generally turn up as graduate thesis topics rather than shrink-wrapped software in the business software aisle. What's more, with either of these, you still have to guarantee the physical integrity of the machine -- if the bad guy can sneak in and install a hardware keyboard sniffer, come back a month later, and take your disk & the keyboard sniffer away, then your encrypted hard disk becomes merely an annoyance. (And when is the last time you performed a chip and component level audit of your hardware resources? Would you even *recognize* a hardware keyboard sniffer if you opened your keyboard up and found its brains?)

I can do perfect security for you. Have a write-only disk.

But in the real world, security is a compromise, between:

	cost
	utility
	protection from bad guys

So far, for most people, the utility of being able to handle damaged filesystems, and the cheap speed of unencrypted data transfers, outweighs the protection from bad guys thing. For most people, securing adequate physical security for the machine, and running an OS and network infrastructure that's effective at stopping vandals, offers sufficient functionality.

                                        -Marcus Watts Received on Fri Feb 28 12:59:15 2003