OpenBSD Journal

Encrypted filesystems?

Contributed by jose on from the privacy dept.

(void *)null writes:
"OpenBSD has the mantra of "crypto everywhere". This includes the network, the swap space, everywhere... except for the filesystem itself! Let's face it, physical security of servers is not always what it should be, and sometimes the costs of fixing physical security problems are out of budget. Encrypted filesystems would add a tremendous layer of safety. If the box is stolen, it would be impossible to recover useful data from it, unless somehow it is stolen with the UPS attached."

"Unfortunately, OpenBSD's FS doesn't have good built-in crypto filesystem support. Loopback is an option, but not something you would want to use in a production system with important data on it.

So, is there any hope for solid crypto FS support in future versions of OpenBSD? Or should the mantra change to "crypto almost everywhere"? Suse and Mandrake Linux both have it, and Windows XP even has it. Will OpenBSD get on the crypto bandwagon? One possible way this could happen is if ReiserFS is ever ported to OpenBSD.

Thanks for any comments on this."

I had a look at mount_tcfs(8) , but it said it was for developers only. We covered vnconfig recently, but that seemed to have some limitations which leaft it unsuitable for general use. Anything else out there?

(Comments are closed)


Comments
  1. By Anonymous Coward () on http://www.rubberhose.org/

    From the webpage: "Rubberhose is currently available for Linux 2.2. Userland daemons and tools are highly portable. NetBSD & FreeBSD kernel modules are nearing completion."

    Might be nice to see OpenBSD support added in the future as well - but we'll see.

  2. By Partisan () ntobik@hotmail.com on mailto:ntobik@hotmail.com

    Last I checked I used CFS from the ports tree in OpenBSD 2.8. It's a cryptographic filesystem that's pretty tightly integrated w/ the system. Had no performance decline from using it, worked like a charm. I'm pretty sure it's been there a while, and last time this issue was brought up it was mentioned as well.

    Nate

  3. By Anonymous Coward () on

    http://www.freebsd.org/cgi/getmsg.cgi?fetch=14565+17609+/usr/local/www/db/text/2002/freebsd-current/20020602.freebsd-current


    Thoughts?

  4. By schubert () on

    Ok here's the deal with production/mission-critical data, encryption protection and the loss of protection from theft or unauthorized eyes....

    If the data NEEDS strong encryption so if, in the event the machine is stolen, or whatever... you must be prepared for the loss of that information. If you aren't prepared to lose that information, then any method of encryption is useless because you aren't prepared for the problems in a faulty encryption system that scrambles things, lost passwords which makes the data unrecoverable or a hardware failure which hoses the data anyways.

    That said there is still a need for it (think military secrets), where, in the event the data being compromised whether being stolen or by failure, its better for NOBODY to have the information then to risk letting the enemy have it. But unless you accept that risk that you might lock yourself out or trash it, you shouldn't consider it.

    It also comes down to the issue of whether you really need filesystem-wide encryption... the benefit of course is privacy.. and to eliminate the fact that specifically encrypted files are a big fat target when people are looking for the good stuff, if you're just wanting to keep missy from looking at your "image collection", stick with less encompassing schemes like cfs or something else.

    As for the "wouldn't it be cool" factor... yeah it would be cool if someone wrote it instead of speculating on how cool it would be.. it'd also be cool if hard drives never failed, cd's never scratched and software bugs didn't exist.

  5. By francisco () on http://www.blackant.net/

    how would backups for encrypted file systems work? dump and tar work on a file basis, so presumably you'd have to backup the actual device using something like dd. that means you'd have to have backup media that can support the entire size of your fs, as you won't be able to tell which parts actually contain files and compression will be useless (strong encrypted data will be quite apparently random and uncompressable).

    that sounds real nasty so maybe you could use tar and dump provided you pass the data through an encrypting filter before it reaches the media.

  6. By RC () on

    From reading the comments on this thread, I've discovered that most people on deadly.org are not paranoid enough to be decent system administrators.

  7. By pixel fairy () on http://pixel.fairyden.net

    the link above covered vnconfig and the lack of HMAC protection which simply means someone can transperantly alter your data without you noticing immediately (at least theoretically)

    so, have a really small root partition, encrypt everything else,and keep a cd you can mount to check all files in the root partition. if the other partitions dont mount, they were tampered with.

    this is something good for laptops that may be stolen or tampered with (ie trojaned) without the
    users knowledge.

  8. By Phoenix () phoenix@dominion.ch on mailto:phoenix@dominion.ch

    Why do we ship cryptography?

    In three words: because we can.

  9. By Don't Got None () on

    I hope you don't mean EFS for windows. Funny thing that, it keeps the password for your 'encrypted' share obfuscated on the disk, if your thief grabs the machine and changes the user password with a boot disk (pretty easy) then they can see your 'encrypted file system'...all the disadvantages of crypto with none of the advantages... I love MS. The Trusted(TM) computing platform of the masses.

  10. By Anonymous Coward () on

    Some others have pointed this out indirectly, but let's be explicit.

    You have no need to encrypt your basic system. If you're paranoid you can store a set of checksums on a CD to verify that the executables haven't been compromised, but it's generally a waste of time to encrypt the contents of /usr, /bin, etc.

    However, a laptop or intrinsically insecure system (e.g., in a dorm room) could decide to encrypt some partitions. /home, maybe some spool directories (e.g., protecting undelivered mail, unprinted documents, etc.), plus the swap space.

    If you do it right, the part that's unencrypted could be a generic installation and everything that's encrypted could go onto a separate disk. In an insecure server environment, you could even mount the disk in one of those removable trays and lock your encrypted disk into a safe overnight. Even a student in a dorm room can get a cheap fire safe from Target and toss a disk into it when it's not in use, and that will probably provide better security than the encryption since it will be so easy for roommates and others to observe him typing it in.

    (Do not underestimate this - in college, I once freaked somebody out by telling them the root password after hearing them type it once. I could figure it out from the slightly different sound of the keys and the timing of their keystrokes.)

  11. By Avery Roberts () averyroberts@hotmail.com on mailto:averyroberts@hotmail.com

    u could build a cd boot that has a encrypted filesystem on it with only the boot loader/decryption engine the only plain code/text on the cd , if u want to use a swap space on a hd use the slack space and have it encrypted , or if all the drives are used and it has a windows system use the same file name + location as the windows swap file on the hd so it is overwriten on windows boot , encrypt that too , anyone interested in building one contact me

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]