Bug 157301

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  
laptop. :-)  
  
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  
solution.  
  
What this would require is pretty much creating a random key, I used something  
like  
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):


How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 
2. Steal a laptop 
 
   

Actual Results:  $$$$ profit. 

Expected Results:  A sad panda.  

Additional info: