3:13 p.m.
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
3:43 p.m.
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
12:26 p.m.
Louis E Garcia II (louisg00(a)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
3:37 a.m.
On Mon, Mar 24, 2008 at 13:26:47 -0400,
Bill Nottingham <notting(a)redhat.com> wrote:
Louis E Garcia II (louisg00(a)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.
4:38 a.m.
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.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
4:45 a.m.
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.
9:26 a.m.
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.
10:12 a.m.
On Tue, Mar 25, 2008 at 14:26:34 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)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).
12:37 p.m.
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?
-Thanks
The Fedora 9 installer supports encrypting everything except /boot, and actually
makes it quite easy.
-- Chris
5869
days inactive
5871
days old
8 comments
8 participants
participants (8)
-
"Jóhann B. Guðmundsson" -
Andrew Farris -
Bill Nottingham -
Bruno Wolff III -
Chris Snook -
Louis Garcia -
Ralf Ertzinger -
Till Maas