Thank you both for your replies!
Thank you for the replies! I have learned a lot from this posting... I
knew to seed a looped file with random data, but had not thought about
seeding the device itself.
The basic commands that were (should have been) run were:
cryptsetup –-verbose –-verify-passphrase create sda3 /dev/sda3
pvcreate /dev/mapper/sda3
vgcreate loggroup /dev/mapper/sda3
lvcreate -L##G -n logvolume loggroup
mkfs.ext3 -j /dev/loggroup/logvolume
mount /dev/loggroup/logvolume /mount_point
I'm basically the Architect who came up with the process to run for the
company, the S/A who setup the box actually ran the commands, the ones I
delivered to him were to build out an encrypted filesystem ontop of an
existing (loop). He made a change to them to use the actual device and
they could have easily enough converted the commands to
pvcreate /dev/sda3, vgcreate loggroup /dev/sda3 and the rest doesn't
matter, nothing would be encrypted.
I think the way I can prove this (please let me know if this has faults)
is in tearing down (unmounting, and vgchange/lvchange) the filesystem
and removing the cryptsetup... At that point the LVM should not
recognize the loggroup as a valid LVM and therefore (vg/pv/lv)display
wont display anything for the subject groups.... So, I think I am
comfortable enough proving that we are (or are not) using the encryption
that way.
What I think has happened was that these devices were in fact used
previously, and we did not seed the devices with random data... I
verified that with the S/A who ran the commands to setup the box.
The only reason we were looking at sda3 was to give the testers a way to
make them feel better that the disk was in fact encrypting the data, are
there better ways to ensure the data stored on the disk is in fact
encrypted?
TIA again!
-chris
Ellison, Bob wrote:
Also, did you initialize the partition with random data before the
cryptsetup step? If not, you could be looking at stale, unencrypted
data.
e.g
dd if=/dev/urandom of=/dev/sda3
or
/sbin/badblocks -c 10240 -s -w -t random -v /dev/sda3
Either will do; the choice is how secure you want your actual data
and/or how long you're willing to wait for the seeding to complete.
--
bob
-----Original Message-----
From: dm-devel-bounces@xxxxxxxxxx [mailto:dm-devel-bounces@xxxxxxxxxx]
On Behalf Of Jonathan Brassow
Sent: Wednesday, August 01, 2007 10:43 AM
To: device-mapper development
Subject: Re: encrypted filesystem not encrypted?
I'm guessing that you are bypassing your crypt device. Depends on
what your arguments are to the LVM commands.
cryptsetup will create a new device that sits on top of sda3 - you
should use that one. Do not use sda3 directly.
brassow
On Jul 31, 2007, at 8:08 PM, chris wrote:
Hi all,
I was not sure which list to send this to, so I choose a couple
that looked like decent fits, please advise if there is one more
specific to the encryption.
I am currently working on a project where we are converting some of
our filesystems to an encrypted fs using LVM2. We are running
RHEL: "2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 12 17:59:08 EDT 2007 i686
i686 i386 GNU/Linux"
We setup an encrypted filesystem using one of the open partitions
on the physical hard drive using "cryptsetup create /dev/sda3" We
have verified this using the cryptsetup status, This shows the
filesystem as being encrypted as aes_plain 256 bit key. We then
created an LVM and mounted the filesystem using the LVM.
All seems to be well, except when our testers ran the following
command:
head -c 5000 /dev/sda3
They got some output that includes clear text and obviously not
encrypted data (along with encrypted data). Some things are date
formatted strings like 20050912 which appears quite a few times in
the mounted filesystem, and in the raw device (/dev/sda3).
I can post the exact commands that were used to create the
filesystem, but they are basically
create partition ...sda3
cryptsetup create /dev/sda3 (prompts for passphrase)
pvcreate
vgcreate
lvcreate
mount
(TIA) any help (or light shed on this) is greatly appreciated!
-chris
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
