Why would you encrypt the whole disk? /home is where your data is the rest is just a regular fedora installation? Is SWAP important to?
-Thanks
On Sun March 23 2008, Louis E Garcia II wrote:
Why would you encrypt the whole disk? /home is where your data is the rest is just a regular fedora installation? Is SWAP important to?
Yes, swap may contain sensitive data, too. Also /root, /var, /tmp, /etc and /usr/local and probably every other location, because one may always make a mistake and copy something to an unencrypted location of the harddisk.
Regards, Till
Louis E Garcia II (louisg00@bellsouth.net) said:
Why would you encrypt the whole disk? /home is where your data is the rest is just a regular fedora installation? Is SWAP important to?
Some people may do it because they have a laptop or similar single-disk system where it's not worth the effort to do a lot of custom partitioning.
Bill
On Mon, Mar 24, 2008 at 13:26:47 -0400, Bill Nottingham notting@redhat.com wrote:
Louis E Garcia II (louisg00@bellsouth.net) said:
Why would you encrypt the whole disk? /home is where your data is the rest is just a regular fedora installation? Is SWAP important to?
Some people may do it because they have a laptop or similar single-disk system where it's not worth the effort to do a lot of custom partitioning.
One advantage to businesses of encrypting everything is you can avoid having to do notifications if the laptop is stolen if you can establish that the thief can't practically get to the data. Since /boot isn't writeable by normal users you don't have to worry about that, but /var/tmp, /tmp would be problems. At the level of these laws I don't think swap and vulnerabilities that allow you to read memory (and the disk keys) if you steal the machine with power on (including suspend to memory) are relevant.
Bruno Wolff III wrote:
I don't think swap and vulnerabilities that allow you to read memory (and the disk keys) if you steal the machine with power on (including suspend to memory) are relevant.
You're probably right about that, but they should be relevant. If a machine containing my information is lost/stolen I do not care whether the company thinks their encryption on it was *probably* good enough, I should be notified the information is out of their control.
Hi.
On Tue, 25 Mar 2008 02:38:38 -0700, Andrew Farris wrote:
You're probably right about that, but they should be relevant. If a machine containing my information is lost/stolen I do not care whether the company thinks their encryption on it was *probably* good enough, I should be notified the information is out of their control.
Even assuming the memory-pull-attack is technically feasible and workable under non-lab conditions I (as an attacker) would rather go against weak passwords or use trojans to get your secret data. I don't think that throwing all our resources on this specific attack is a good use of our time.
Ralf Ertzinger wrote:
Hi.
On Tue, 25 Mar 2008 02:38:38 -0700, Andrew Farris wrote:
You're probably right about that, but they should be relevant. If a machine containing my information is lost/stolen I do not care whether the company thinks their encryption on it was *probably* good enough, I should be notified the information is out of their control.
First of all company's should never allow *employees* to leave with security/corporate sensitive data from the premise's in the first place. Be it on encrypted or not laptop's or any portable media format. ( But then again they should not be mailing them either :) )
Second of all if the company is <sarcasm>*smart*<sarcasm> enough to allow laptop or other portable media that contains security/corporate sensitive data leave the premise's in the first place and then when that *data* gets *misplaced*, all parties involved should be notified that the *information* is lost immediately.
Time is of the essence here..
In reality the scenario is more like this..
John Doe loses or *misplaces* the sensitive data, ( or is asked to mail it ) wastes couple of hours looking for ( or the people at the post office ) it and then finally reports the lost *data*, that is if he does not report it the following morning or he realizes that he's ( probably ) gonna get fired ( yep him not the CEO/Goverment employee that allowed this to leave the premises in the first place ) and wastes more hours reflecting on his current situation. ( Depends on which sector your working in if you get trained to handle these situation )
The report gets in what happens now... Damage control meetings yea!!! let's waste more time on that.. Then couple of days ( if lucky, more likely week or more ) Parties/Clients/Public is notified of the data loss and the person that lost the data got fired and they are assured the data was "encrypted" and "unaccessible " by any means known to man, and if so *unlikely* the data is in the hands of a criminal then that criminal is made out to be a common thief and or a drug user finding ways to finance his next fix (something "low crime" people can commonly relate to instead of the actual real threat )..
This has given the attacker more than enough time to execute the second stage of his attack and or disappear..
Even assuming the memory-pull-attack is technically feasible and workable under non-lab conditions
It it's.
I (as an attacker) would rather go against weak passwords or use trojans to get your secret data. I don't think that throwing all our resources on this specific attack is a good use of our time
I think there are others protecting their asset(s) that are working on finding a solution to this problem and if/when they manage to come up with one i'm sure it will find it's way to the open source community....
All I was suggesting that where you "hash" encrypt in anaconda there would be a notification telling the user(s) that thou he encrypted the drive it would be vulnerable to "cold boot" attack. something along with line it's better to encrypt but it's not secure even thou governments and corporates have claimed it to be.
No need to be promoting false security..
Best regards Johann B.
On Tue, Mar 25, 2008 at 14:26:34 +0000, ""Jóhann B. Guðmundsson"" johannbg@hi.is wrote:
All I was suggesting that where you "hash" encrypt in anaconda there would be a notification telling the user(s) that thou he encrypted the drive it would be vulnerable to "cold boot" attack. something along with line it's better to encrypt but it's not secure even thou governments and corporates have claimed it to be.
No need to be promoting false security..
While the various methods of dumping memory contents in order to retrieve a liuks partion key are real, the fact they they exist doesn't make using luks encryption insecure. You may also need to worry about keyloggers, cameras, shoulder surfing getting the box hacked while the file systems are mounted and connected to a network or even the old rubber hose method. That depends on your threat model.
I am not sure a warning at that point is worthwhile. Instead the limitations of encrypted file systems should be covered in the same place(s) the feature is documented. If the install points the user to anything during the install process it should be to the feature description (possibly in the release notes if it is well documented there).
-
"Jóhann B. Guðmundsson" -
Andrew Farris -
Bill Nottingham -
Bruno Wolff III -
Chris Snook -
Louis Garcia -
Ralf Ertzinger -
Till Maas