[linux-lvm] LVM and Truecrypt

[linux-lvm] LVM and Truecrypt

[Gordon Fogus]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

Hello all,

I am trying to create a 10TB network share (like a NAS share, but with
permission levels) on a dedicated GNU+Linux server to be used on a
Linux/Windows network.

I must use truecrypt for full drive encryption.
I need the disks to be independently mountable (no striping, parity bits or
files spanning across physical drives) (this is because I am afraid of
massive data loss from a mainboard failure.  If you can show me that this
fear is unfounded and that I would definitely be able to recover my data
after a mainboard failure, then I would not hesitate to use files spanning
across drives).
Most importantly, the combined space of the disks (10TB) must appear as 10TB
on the network, not 10 @ 1TB drives (if I were using 1TB drives, for
example).
Resonable continuous write speed is also a factor for me.
It is essential that this drive space can be "mounted" (i.e., "mount network
drive") on a Windows machine.
Different folders must be able to have different permissionn levels for
different users, similar to the permission levels available in Microsoft
shares (write new files/edit files/delete files/make new folders/delete
folders/etc.).  After someone connects to the file server, he must not be
able to access every file, only those specificly shared to him.

Can someone point me to info on using truecrypt with LVM?

(I am new to GNU+Linux.  File serving on a Windows Active Directory server
is... unpredictable.)

Gordon

[-- Attachment #2: Type: text/html, Size: 1534 bytes --]

Re: [linux-lvm] LVM and Truecrypt

[Sven Eschenberg]

Hi Gordon,

Is there any particular Reason, why a mainboard failure should result in 
massive data loss?
But you can be assured, that a disk failure in such a volume will most 
certainly result in massive dataloss, since the filesystem spans across 
all disks.
Is there any partuclar reason for using truecrypt?

Regards

-Sven

Gordon Fogus schrieb:
> Hello all,
> 
> I am trying to create a 10TB network share (like a NAS share, but with 
> permission levels) on a dedicated GNU+Linux server to be used on a 
> Linux/Windows network.
> 
> I must use truecrypt for full drive encryption. 
> I need the disks to be independently mountable (no striping, parity bits 
> or files spanning across physical drives) (this is because I am afraid 
> of massive data loss from a mainboard failure.  If you can show me that 
> this fear is unfounded and that I would definitely be able to recover my 
> data after a mainboard failure, then I would not hesitate to use files 
> spanning across drives). 
> Most importantly, the combined space of the disks (10TB) must appear as 
> 10TB on the network, not 10 @ 1TB drives (if I were using 1TB drives, 
> for example). 
> Resonable continuous write speed is also a factor for me.
> It is essential that this drive space can be "mounted" (i.e., "mount 
> network drive") on a Windows machine.
> Different folders must be able to have different permissionn levels for 
> different users, similar to the permission levels available in Microsoft 
> shares (write new files/edit files/delete files/make new folders/delete 
> folders/etc.).  After someone connects to the file server, he must not 
> be able to access every file, only those specificly shared to him.
> 
> Can someone point me to info on using truecrypt with LVM? 
> 
> (I am new to GNU+Linux.  File serving on a Windows Active Directory 
> server is... unpredictable.)
> 
> Gordon
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] LVM and Truecrypt

[Gordon Fogus]

[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]

Hello Sven (and all),

I have been concerned that a failure on one of the disk controllers would
result in data loss in the following way:
1. A mainboard fails that has a JOBD RAID connected
2. The mainboard is replaced and the drives from the original set are
connected.
3. Because of hardware changes and/or operating system changes and/or "disk
order" changes, no data can be read from the RAID.
I'd be curious to know this: if I had a JOBD under LVM and I tried to plug
the disks into another PC entirely, would I be able to read the files I had
on those drives?  How does LVM know which drive was where in the order of
drives in the JOBD?

I am not actually worried about data loss from a drive failure.  I backup
regularly (but I have never had a hard drive fail.  I attribute this partly
to the temperature at which I keep my drives).  I have had several RAID
controller failures (which is why I no longer consider any RAID level to be
a backup).

By asking, "Is there any partuclar reason for using truecrypt?" do you mean,
"Why truecrypt as opposed to any other encryption solution?"?  If so, I use
truecrypt because it is opensource and has received a lot of attention from
experienced cryptographers.  I wouldn't trust closed source or obscure
encryption software.  On the other hand, if you were asking, "Why use
encryption?", then you might be interested in Sans news bites:
http://www.sans.org/newsletters/newsbites/ .  Sans covers many data leaks.

(Do you live in Scandinavia?)

Gordon

On Wed, May 6, 2009 at 5:08 PM, Sven Eschenberg
<sven@whgl.uni-frankfurt.de>wrote:

> Hi Gordon,
>
> Is there any particular Reason, why a mainboard failure should result in
> massive data loss?
> But you can be assured, that a disk failure in such a volume will most
> certainly result in massive dataloss, since the filesystem spans across all
> disks.
> Is there any partuclar reason for using truecrypt?
>
> Regards
>
> -Sven
>
> Gordon Fogus schrieb:
>
>> Hello all,
>>
>> I am trying to create a 10TB network share (like a NAS share, but with
>> permission levels) on a dedicated GNU+Linux server to be used on a
>> Linux/Windows network.
>>
>> I must use truecrypt for full drive encryption. I need the disks to be
>> independently mountable (no striping, parity bits or files spanning across
>> physical drives) (this is because I am afraid of massive data loss from a
>> mainboard failure.  If you can show me that this fear is unfounded and that
>> I would definitely be able to recover my data after a mainboard failure,
>> then I would not hesitate to use files spanning across drives). Most
>> importantly, the combined space of the disks (10TB) must appear as 10TB on
>> the network, not 10 @ 1TB drives (if I were using 1TB drives, for example).
>> Resonable continuous write speed is also a factor for me.
>> It is essential that this drive space can be "mounted" (i.e., "mount
>> network drive") on a Windows machine.
>> Different folders must be able to have different permissionn levels for
>> different users, similar to the permission levels available in Microsoft
>> shares (write new files/edit files/delete files/make new folders/delete
>> folders/etc.).  After someone connects to the file server, he must not be
>> able to access every file, only those specificly shared to him.
>>
>> Can someone point me to info on using truecrypt with LVM?
>> (I am new to GNU+Linux.  File serving on a Windows Active Directory server
>> is... unpredictable.)
>>
>> Gordon
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 5084 bytes --]

Re: [linux-lvm] LVM and Truecrypt

[Stuart D. Gathman]

On Wed, 6 May 2009, Gordon Fogus wrote:

> 3. Because of hardware changes and/or operating system changes and/or "disk
> order" changes, no data can be read from the RAID.

Does Windows have that "feature"?  Just kidding.  I think your fear
is based on experience with hardware RAID.  Every sane operating system
keeps headers with labels on filesystems and volumes.  Disk order doesn't
matter with LVM, or software RAID. 

> I'd be curious to know this: if I had a JOBD under LVM and I tried to plug
> the disks into another PC entirely, would I be able to read the files I had
> on those drives?  How does LVM know which drive was where in the order of
> drives in the JOBD?

Every physical volume (PV) in LVM has a header (called metadata) with a
unique PV UUID.  Yes, you can read the disks on another PC.

> I am not actually worried about data loss from a drive failure.  I backup
> regularly (but I have never had a hard drive fail.  I attribute this partly
> to the temperature at which I keep my drives).  I have had several RAID
> controller failures (which is why I no longer consider any RAID level to be
> a backup).

I always use software RAID1.  Negligible overhead on server, no fancy
hardware RAID controllers to fail.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] LVM and Truecrypt

[Sven Eschenberg]

Hi Gordon,

As someone explained already, LVM writes metadata on each Physical 
Volume (read: disk or disk partition or any other block device), if you 
fancy it, you can even save two copies (just in case one copy gets 
corrupted due to some failure, bad sector or whatever).
The Metadata gives you the opportunity to change diskorder, move disks 
to different controllers (as in move some of the disks from one 
controller, to another controller in the machine), or any other machine, 
as long as you got the whole set at hands.
(Now that I am thinking about it, you could even place all n disks into 
n different machines and create an LVM from them, though this might be a 
little more tricky, than the other scenarios)

As an alternative, you could use md devices (offering different software 
based raid levels), md does indeed provide the same features (in 
example, you have a raid 5 volume with n drives, you can choose any n-1 
drives of those, stick em into another machine, and use the raid, add 
another disk, integrate it into the array and rebuild it).
So, for both cases, md based raid and lvm, there's metadata, no worries 
there.
Most HW Raidcontrollers (Tekram, Adaptec, 3ware ...) usually save 
metadata information on disks too, the major problem is getting a new 
(expensive) card from the same vendor.

Concerning encryption, I was asking, because if you use linux as OS on 
your NAS and linux solely, you could use dmcrypt (which is used by 
truecrypt on linux too, if available) which gives you more options on 
encryption etc. (Choose any cipher from the kernel crypto api, luks key 
managment ...). This is usually integrated far better into 
distributions, than truecrypt.
In case you want to avoid the luks header (since it indicates some info 
on the crypted volume, offers multiple key slots etc.) you can still 
revert to non-luks mode with dm-crypt and still enjoy all the ciphers 
from the kernel (and modes of operation).
Concerning truecrypt: Truecrypt always uses XTS afaik, you certainly 
would not want to encrypt a 10 TB volume with that.
(http://en.wikipedia.org/wiki/XTS#XTS)

And for your last question, no I live in Germany actaully (hence the .de 
domain)

Regards

-Sven



Gordon Fogus schrieb:
> Hello Sven (and all),
> 
> I have been concerned that a failure on one of the disk controllers 
> would result in data loss in the following way:
> 1. A mainboard fails that has a JOBD RAID connected
> 2. The mainboard is replaced and the drives from the original set are 
> connected.
> 3. Because of hardware changes and/or operating system changes and/or 
> "disk order" changes, no data can be read from the RAID.
> I'd be curious to know this: if I had a JOBD under LVM and I tried to 
> plug the disks into another PC entirely, would I be able to read the 
> files I had on those drives?  How does LVM know which drive was where in 
> the order of drives in the JOBD?
> 
> I am not actually worried about data loss from a drive failure.  I 
> backup regularly (but I have never had a hard drive fail.  I attribute 
> this partly to the temperature at which I keep my drives).  I have had 
> several RAID controller failures (which is why I no longer consider any 
> RAID level to be a backup).
> 
> By asking, "Is there any partuclar reason for using truecrypt?" do you 
> mean, "Why truecrypt as opposed to any other encryption solution?"?  If 
> so, I use truecrypt because it is opensource and has received a lot of 
> attention from experienced cryptographers.  I wouldn't trust closed 
> source or obscure encryption software.  On the other hand, if you were 
> asking, "Why use encryption?", then you might be interested in Sans news 
> bites: http://www.sans.org/newsletters/newsbites/ .  Sans covers many 
> data leaks.
> 
> (Do you live in Scandinavia?)
> 
> Gordon
> 
> On Wed, May 6, 2009 at 5:08 PM, Sven Eschenberg 
> <sven@whgl.uni-frankfurt.de <mailto:sven@whgl.uni-frankfurt.de>> wrote:
> 
>     Hi Gordon,
> 
>     Is there any particular Reason, why a mainboard failure should
>     result in massive data loss?
>     But you can be assured, that a disk failure in such a volume will
>     most certainly result in massive dataloss, since the filesystem
>     spans across all disks.
>     Is there any partuclar reason for using truecrypt?
> 
>     Regards
> 
>     -Sven
> 

RE: [linux-lvm] LVM and Truecrypt

[Gaute Lund]

Gordon Fogus wrote Thursday, May 07, 2009 4:20 AM

> On the other hand, if you were asking, "Why use encryption?", then you
might be 
> interested in Sans news bites:
http://www.sans.org/newsletters/newsbites/.� 
> Sans covers many data leaks.

I might add: You're aware that block-level/disk-level encryption offers only
protection against someone stealing your box/disks, or otherwise compromise
it physically?

Remote "attacks" will be just as effective against a box with
truecrypt/dm-crypt!

-gaute

Re: [linux-lvm] LVM and Truecrypt

[Gordon Fogus]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

Gaute Lund: "I might add: You're aware that block-level/disk-level
encryption offers only
protection against someone stealing your box/disks, or otherwise compromise
it physically?"

I am not concerned with physical security of the machine while it is running
nor with using encryption to protect myself against remote attacks.
Excellent point though.

Sven Eschenberg: "Concerning encryption, I was asking, because if you use
linux as OS on your NAS and linux solely, you could use dmcrypt (which is
used by truecrypt on linux too, if available) which gives you more options
on encryption etc. (Choose any cipher from the kernel crypto api, luks key
managment ...). This is usually integrated far better into distributions,
than truecrypt."

Wow, Linux has built in crypto.  Windows has... :(  I will check this out.
I guess this means I need to get used to typing into the command box to do
everything.  I am using a 6TB RAID5 currently (5TB usable).  I find it
unbearably slow compared to my 4TB RAID0+1 (2TB usable).

Sven Eschenberg: "In case you want to avoid the luks header (since it
indicates some info on the crypted volume, offers multiple key slots etc.)
you can still revert to non-luks mode with dm-crypt and still enjoy all the
ciphers from the kernel (and modes of operation)."

Yes, I would definitely prefer not to have a header that says: "Secrets lurk
beyond".

Sven Eschenberg: "Concerning truecrypt: Truecrypt always uses XTS afaik, you
certainly would not want to encrypt a 10 TB volume with that.
(http://en.wikipedia.org/wiki/XTS#XTS)"

Ohhhh bother!  You sound like you know crypto better than I.  What mode of
operation do you recommend?  Is there a distro you would recommend for
crypto above others?  I was thinking of using Ubuntu because it has such a
large support base.

Sorry, I didn't look at your address.  I was in Frankfurt a few years ago.
Have you been to CCC ever?

Gordon


On Thu, May 7, 2009 at 12:39 AM, Gaute Lund <gaute@idrift.no> wrote:

> Gordon Fogus wrote Thursday, May 07, 2009 4:20 AM
>
> > On the other hand, if you were asking, "Why use encryption?", then you
> might be
> > interested in Sans news bites:
> http://www.sans.org/newsletters/newsbites/.
> > Sans covers many data leaks.
>
> I might add: You're aware that block-level/disk-level encryption offers
> only
> protection against someone stealing your box/disks, or otherwise compromise
> it physically?
>
> Remote "attacks" will be just as effective against a box with
> truecrypt/dm-crypt!
>
> -gaute
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

[-- Attachment #2: Type: text/html, Size: 3660 bytes --]

Re: [linux-lvm] LVM and Truecrypt

[Charles Marcus]

On 5/6/2009, Stuart D. Gathman (stuart@bmsi.com) wrote:
> Disk order doesn't matter with LVM, or software RAID.

Or with my 3ware controllers...

-- 

Best regards,

Charles

Re: [linux-lvm] LVM and Truecrypt

[Sven Eschenberg]

Hi Gordon,

The kernel crypo API carries a vast selection of ciphers, hash functions 
and mode of operation (or rather block chaining algorithms). Most of 
them are used for ipsec too (ciphers and hashes), thus I am somewhat 
confident they are rather well revised. if you use a precompiled kernel, 
just do a cat /proc/crypto, it will list, what's available, if the 
ciphers etc. are modular, you might need to modprobe the modules you 
plan to use first.

I personally use luks headers, for easier handling, because I can assign 
keys via UUIDs, by plugging in a usb stick during boot (you could aswell 
probably write an init-script that waits for the keys to be transmitted 
via network ...)

The problem with volumes >>1TB seems to be 'omnipresent' cbc-essiv etc. 
show the same weakness, from what I gathered (I am no expert here), this 
  is a general consideration, if you have enough data for a statistical 
attack chances get bigger to break the encryption, if an adversary is 
able to write data to the device, and thus knows the unencrypted data 
aswell as the encrypted data. There seems to be a new mode of operation 
(or algorithm for block chaining) which reduces those chances further.

There was a discussion on the dm-crypt list, to automatically slice huge 
volumes in chunks, and use key splitting (or some sort of derivation) to 
get multiple keys for the chunks.

I chose another option, let's assume you haave n disks, let's call them 
/dev/sda through /dev/sdn for now. create an encrypted blockdevice via 
dm-crypt for each of those, for the sake of easiness we give them 
symbolic names, let's say crypt-a through crypt-n, with n different 
keyys. (On the assumption that every physical device is smaller than 
1TB). The crypted blockdevices behave exactly like physical disks, thus, 
you can partition them, or you can create PVs for LVM usage, or you can 
use md(raid) to form a raid volume out of them.
You can stack md/devmapper/dm-crypt devices on top of each other as you 
please, but always consider, more layaers could potentially produce 
errors, if any of the layers might have a bug/failure, this should be 
taken into account, tough it's a locigal thing.
Advantages of such a setup are:
1.) each disk has an own key, thus you need to break n keys, if you want 
to acces ALL data in clear
2.) no matter if the crypto algorithm is parallelized, each disk gets 
it's own dmcrypt kernel thread, which in turn can be scheduled onto 
different cores and cpus, thus yielding in a better performance, if you 
have multiple cores/cpus and the algorthim itself is not prallelized.
But it needs a little more work in the setup, since you need to provide 
multiple keys.

Example for clarification:


/dev/sda becomes /dev/crypta, /dev/crypta can be used like /dev/sda, 
after providing the key, cipher algorithm etc. to cryptsetup.
Now instead of putting your PV Header/Metadata onto /dev/sda, you use 
/dev/crypta, thus the metadata gets encrypted aswell as all the data in 
the PV. The PV's Metadata holds information about your VolumeGroup and 
Logical volumes, in your case as I understood it, you will have one 
VolumeGroup consisting of those n dm-crypt devices, and one 
LogicalVolume, with one giant filesystem.

If you wanna access files from windows easily, you'd then setup samba, 
and export the filesystem or directories in the filesystem via samba.
Make sure, you use a filesystem with ExtendedAttributes/Posix ACLs, have 
support for it in the kernel and in samba. If you set it up properly, 
you can access the volume or the directories exported, from windows, you 
can even manage user permission on the filesystem from your windows 
client, in the same manner you can on local disks. This will need some 
fiddling and testing around, but I can assure you it works :-).

 From what I know, luks/dm-crypt support is tied pretty well into 
ubuntu,  eventually check the ubuntu wiki, there's some articles for 
setting up dmcrypt etc. right from the beginning, if you'd want to hold 
the actual system on those crypto devices and boot of them aswell, for 
the latter, you need to choose some alternate setup media if I remember 
correctly.

Personal sidenote: Nopes, nevr made it to CCC unfortunately, but it's on 
my agenda, of things a man should do in his life :-)


Hope my mail helps a little in understanding possible setups ;-).

Regards

-Sven


Gordon Fogus schrieb:
> 
> Sven Eschenberg: "Concerning encryption, I was asking, because if you 
> use linux as OS on your NAS and linux solely, you could use dmcrypt 
> (which is used by truecrypt on linux too, if available) which gives you 
> more options on encryption etc. (Choose any cipher from the kernel 
> crypto api, luks key managment ...). This is usually integrated far 
> better into distributions, than truecrypt."
> 
> Wow, Linux has built in crypto.  Windows has... :(  I will check this 
> out.  I guess this means I need to get used to typing into the command 
> box to do everything.  I am using a 6TB RAID5 currently (5TB usable).  I 
> find it unbearably slow compared to my 4TB RAID0+1 (2TB usable).
> 
> Sven Eschenberg: "In case you want to avoid the luks header (since it 
> indicates some info on the crypted volume, offers multiple key slots 
> etc.) you can still revert to non-luks mode with dm-crypt and still 
> enjoy all the ciphers from the kernel (and modes of operation)."
> 
> Yes, I would definitely prefer not to have a header that says: "Secrets 
> lurk beyond".
> 
> Sven Eschenberg: "Concerning truecrypt: Truecrypt always uses XTS afaik, 
> you certainly would not want to encrypt a 10 TB volume with that.
> (http://en.wikipedia.org/wiki/XTS#XTS)"
> 
> Ohhhh bother!  You sound like you know crypto better than I.  What mode 
> of operation do you recommend?  Is there a distro you would recommend 
> for crypto above others?  I was thinking of using Ubuntu because it has 
> such a large support base.
> 
> Sorry, I didn't look at your address.  I was in Frankfurt a few years 
> ago.  Have you been to CCC ever?
> 
> Gordon
> 
> 
>