Red Hat Bugzilla – Bug 157301
Enhancement: Encrypted partitions option to prevent information theft with hardware
Last modified: 2007-11-30 17:11:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.0 (like Gecko)
Description of problem:
As far as I have understood Fedora is trying to be a) test bed for RedHat b)
"Create a complete general-purpose operating system with capabilities
equivalent to competing operating systems" and nice stuff like that (from the
objectives page from Fedora.org).. And I got to thinking about this thing.
One of the large problems around, especially with laptops, is that they get
stolen. Crackheads snatch them from cars and such and even sometimes someone
is after the information that is on the hdd. The amount of it happening is
alarming. It poses a danger especially for enterprise users and alike and with
the competing operating systems they are rolling out hard disk encryption
schemes to minimize the security problem. Those products can cost substantial
amounts of money to the companies. 10-100eur/installation? Depends greatly on
the quality etc of the chosen solution.
Couldn't Fedora Core give an option to encrypt some partition(s) or provide
some other solution for the problem? It's a bit tricky since the multi-user
setups and such are harder to setup though.. But most of the laptops have got
single users anyway and those are the main target (imho). The main tools
however are not complex. I believe that in the long run the commercial Redhats
would benefit from the feature as well (unless if they already have got that,
I am not very familiar with them.).
I built myself manually an usb stick that does the stuff at boot time. It's a
bit rude but I think I will share couple of my experiences.
Dm(-crypt) is already available in the kernel and the tools are quite simple
and small. There are however a few pitfalls. The kernel, initrd and such have
to remain on an unencrypted space for obvious reasons. The same goes for the
master encryption keys (that would be unencrypted to be able to mount the
devices). It is also perhaps irrelevant to protect common system data such as
the Fedora itself. There are easier ways to obtain Fedora than stealing a
However making sure /tmp and couple other alike places do not reveal backup /
working copies of the files (even the nodes unlinked) must be taken care of.
Especially when shred and alike can't guarantee their working on journaled
filesystems (blah.). I used tmpfs for those couple spots but it's a bad
What this would require is pretty much creating a random key, I used something
dd if=/dev/urandom of=key1 bs=32 count=1
and asked for the user's password, hashed it to 32byte (256bit) SHA and XOR'ed
with the master key. A setup like this allows the user to change his password.
Dm-crypt device's master key can't be at the moment changed afterwards.
Then just for instance
echo 0 size-of-partition crypt twofish-cbc-essiv:wp256
the-key-in-hexadecimal-form 0 /dev/blahblah 0 | /sbin/dmsetup create mydevice
and you can mkfs & mount the /dev/mapper/mydevice
And voila. Encrypted partition. Just add password changing tool, perhaps
backup (disc?) creating tool to the later userspace and such. You've got a
quite securely encrypted storage space there. Just update fstab for it and
stuff like that, query the user for the password at bootup (or whenever you
like). The data should be quite safe. Stealing the whole package gives you
just the master key that is XOR'ed with the hash. Have "fun" brute forcing
256-bit sha, hehe.. MY passwords are all 30+ characters long and contain all
kinds of funky stuff.
There are couple ready tools that simplify the matter. Check out
http://www.saout.de/misc/dm-crypt/ and naturally
http://luks.endorphin.org/dm-crypt but I found out they don't support (well)
my hash and encryption algorithm choices. You would want to go for SHA/AES
though I bet.
In overall the feature should not be a hard thing to support in Anaconda and
in general in the Fedora once you gather a bit of information. It has seemed
quite stable for me as well, I haven't been able to destroy any data or
anything like that yet. Would require some coordination between Anaconda and
the security peeps.
An other approach would be giving later userspace tools for mounting encrypted
file based containers for storing certain information more securely. It can
however have security pitfalls when the container is on top of journaled
filesystem I heard.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora
2. Steal a laptop
Actual Results: $$$$ profit.
Expected Results: A sad panda.
Is this a duplicate of bug 124789?
*** This bug has been marked as a duplicate of 124789 ***