[PLUG] Secure filesystem?

[Bear Giles]

Alex Daniloff wrote:
> I'm not trying to comply with anything. This solution should solve
> data security problems in some business operations.

I understand that, but if you get 3 people together you'll have at least 
4 different opinions on what the "data security problems" are.  We need 
to know what YOU consider to be the problem before we can give specific 
advice.

> Imagine situation, when burglars,FBI,CIA or other crooks are breaking
> into your office and taking your server or hard drive away to look
> into your secret data files.

If you're worried about the FBI or CIA, I'm not sure how much I want to 
help.... It's not that I trust them, but if they have a search warrant 
they can demand the decryption key and search the disk anyway.  If you 
want to prevent this, you want to be ready to commit obstruction of 
justice and that makes me wonder why.

At the same time, I fully understand the need to protect legally 
confidential material (financial, medical, etc.  People have found 
highly sensitive material, e.g., names and HIV test results, on 
discarded disks) or trade secrets from competitors and have no problem 
helping you protect this information.

(BTW, if you're serious you'll also store the disk's serial number 
inyour safe.  Why should the bad guys bother stealing your disk, copying 
it, and then risking getting it back into your machine when they could 
just swap in a bad disk?)

Anyway, this means your solution must involve one of the on-disk 
encryption approaches.  I tend to favor the loopback filesystem with 
encryption, but once mounted anyone with access to your filesystem can 
see all of the files on the encrypted disk, modulo the regular 
permissions.  Others prefer the CFS approach, which uses a specialized 
NFS server, since it doesn't make the contents available to everyone on 
the system and it doesn't require you to set aside dedicated space for 
it.  (That also means that somebody can immediately identify all of the 
space consumed by encrypted files - with the loopback device you don't 
know if an encrypted GB partition is empty or full.)

The other concern is that you need to be able to export whatever 
solution you use.  I think a "loopback" approach is much lower than a 
CFS approach - you can probably export a loopback FS via NFS or Samba, 
but may not be able to do so with CFS.  But I could easily be wrong 
about this.  (As a rule "like can't export like," so I doubt NFS can 
export a partition mounted by NFS/CFS.)

> Securing data in transit is also very important, but there are many
> different concepts were developed already to cover this area.

That's not the only concern.  What about somebody who copies the 
exported files to ZIP disk or CD-R file on the client system?  Or email 
a copy of the file to somebody outside of the company?  It makes no 
sense to install a heavy steel door while you leave the windows wide open.

Bear