| View previous topic :: View next topic |
| Author |
Message |
ycUygB1
Apprentice
Joined: 27 Jul 2005
Posts: 276
Location: Portland, Oregon
|
 Posted: Sat Jan 21, 2006 6:48 pm Post subject: automatic mounting of LUKS /home partition |
 |
|
The documentation for LUKS is in a very sorry state. I knew I was in trouble when the docs said
| Quote: | LUKS adds 4 actions to cryptsetup, namely luksFormat, luksOpen, LuksAddKey, and luksDelKey. Although the names are quite
self-explanatory, I'll give brief examples... |
Then no explanation is given about what the commands do, and to make matters worse, there is actually another command "luksClose"
which is not explained either. Enough flaming.
I would like to encrypt /home and have it mounted automatically at boot time.
The encryption password should be required to boot. On shutdown, the partition should
be cleanly unmounted.
Here's what I have done so far:
# cryptsetup -y -s 256 luksFormat /dev/sda6
# crytsetup luksOpen /dev/sda6 /home
# mkreiserfs /dev/mapper/home
# mount /dev/mapper/home /home
# cd /home
# adduser -m harold
Then I added the following line to /etc/fstab:
/dev/mapper/home /home reiserfs noatime 0 2
Now I can create files in /home and then:
# umount /home
# cryptsetup luksClose home
I was a little nervous that this would delete all the data on the encrypted partition,
since there is absolutely no description in the docs about what this command does
other than to say that it is obvious.
But apparently, after this, I can access the data again by
# cryptsetup luksOpen /dev/sda6 home
# mount /dev/mapper/home /home
So things are working, after a bit of finger-crossing and guessing. But now the question is,
how to make this happen automatically at boot time??
Right now, when I boot, I get the error message:
| Quote: | | mount: special device /dev/mapper/home does not exist. |
After booting finishes, I am able to access the data using cryptsetup luksOpen and mount as above.
Also, for the sake of completeness, it might be useful to answer the following questions about
LUKS
1) Please describe the relationship between the "master key" and the other keys that are added
with luksAddKey. For instance, does one generally need both the master key and the second key
in order to access the data? Can you access the data with just the second key? Does each user
have a different key? Can they access each other's data? I know they can delete each other's keys.
That seems weird.
2) What is the relationship between a user's Linux password and the luks Key? Would it be
possible to have each user's password also be a luks key? Is this a good idea?
3) What does luksClose actually do? What does luksOpen actually do? It appears necessary to
"open" the device before mounting it. Why? Why is it necessary to unmount before closing? |
|
| Back to top |
|
 |
ycUygB1
Apprentice
Joined: 27 Jul 2005
Posts: 276
Location: Portland, Oregon
|
| Posted: Sun Jan 22, 2006 3:16 am Post subject: My solution |
|
|
I feel like a rat that went down every possible path in the maze only to find out that the way out of the maze
was right next to me.
Although there doesn't seem to be any documentation on this, it seems that cryptsetup-luks is part
of the baselayout installation (at least in my ~x86). In fact, the cryptsetup package blocks cryptsetup-luks,
so you need to unmerge cryptsetup. You should have a file /etc/conf.d/cryptfs
Here are the steps I took:
1) Compile the kernel with support for tmpfs and dm-crypt
CONFIG_TMPFS=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_DM_CRYPT=y
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_DES is not set
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_DEV_PADLOCK is not set
2) emerge multipath-tools cryptsetup-luks
3) Read http://www.gentoo.org/proj/en/hardened/disk-cryptography.xml and setup your swap as in item 3.
4) For an encrypted /home partition:
| Code: |
# cryptsetup -v -y -c aes -s 256 create crypt-home /dev/sda5
# mkreiserfs /dev/mapper/crypt-home
# mount /dev/mapper/crypt-home /home
|
5) Edit /etc/conf.d/cryptfs:
| Code: | swap=crypt-swap
source='/dev/sda3'
mount='crypt-home'
source='/dev/sda5'
options='-c aes -s 256'
|
6) Check to make sure that things are working with
| Code: | #dmsetup ls
crypt-home (254, 1)
crypt-swap (254, 0)
|
7) Edit /etc/fstab:
| Code: | /dev/sda2 /boot ext2 noatime 1 3
/dev/sda6 / ext3 noatime 0 1
/dev/mapper/crypt-home /home reiserfs noatime 0 2
/dev/mapper/crypt-swap none swap sw 0 0
none /tmp tmpfs defaults 0 2 |
8) Add a user who will use the encrypted /home partition
| Code: |
# useradd -m -G wheel,audio harold
# passwd harold
|
When you reboot, you will be asked for the password in order to mount crypt-home.
It wasn't that hard, after I made every possible mistake. |
|
| Back to top |
|
|
GenKreton
l33t
Joined: 20 Sep 2003
Posts: 828
Location: Cambridge, MA
|
| Posted: Sun Jan 22, 2006 5:03 am Post subject: |
|
|
I recently encrypted my entire / so I have spent some time drudging through the intricacies of dm_crypt luks.
| Quote: | 1) Please describe the relationship between the "master key" and the other keys that are added
with luksAddKey. For instance, does one generally need both the master key and the second key
in order to access the data? Can you access the data with just the second key? Does each user
have a different key? Can they access each other's data? I know they can delete each other's keys.
That seems weird. |
The keys are independent it seems. You can, for example add a key in slot 1 and remove the original key in slot 0. The only pain is in remembering which keys were in which slot. So they act independently to access the very same data.
| Quote: | 2) What is the relationship between a user's Linux password and the luks Key? Would it be
possible to have each user's password also be a luks key? Is this a good idea? |
There is no relationship at all. I would advise against using the same passwords but it doesn't really matter. If someone has spent enough energy accessing your data that they broke your encryption either something was implemented poorly, there was a bug, or you chose very weak passphrases. With that said, if they got that far placing the harddrive in another machine or chrooting from a livecd or such would be trivial.
| Quote: | 3) What does luksClose actually do? What does luksOpen actually do? It appears necessary to
"open" the device before mounting it. Why? Why is it necessary to unmount before closing? |
Someone else can probably explain this better than I. Essentially it readies what they call the device mapper. It is a layer that sits between your physical harddrive and the operating system that is sending data at it. if you sent data right to the hd, there would be no way to encrypt it. These devices you create handle the encryption then pass the data to the physical device. With that said, you have to umount before closing the mapper device because the mapper device will be busy as long as the mapper device is in use (mounted). It could be useful to think of it as a loop device if you are familiar with them.
I hope this helps and I didn't confuse anybody farther. |
|
| Back to top |
|
|
ycUygB1
Apprentice
Joined: 27 Jul 2005
Posts: 276
Location: Portland, Oregon
|
| Posted: Sun Jan 22, 2006 10:54 am Post subject: |
|
|
I think you should consider writing the docs for LUKS, because you explained it a lot better
than the official docs did.
Encrypting / scares me. I suppose you had to make an initrd in order to do this?
What is your thinking about why you should encrypt / and not just /home swap and use tmpfs?
I opted for a simpler solution because it seems to be what Gentoo supports,
and that is usually good enough. |
|
| Back to top |
|
|
GenKreton
l33t
Joined: 20 Sep 2003
Posts: 828
Location: Cambridge, MA
|
| Posted: Sun Jan 22, 2006 6:17 pm Post subject: |
|
|
| hnaparst wrote: | I think you should consider writing the docs for LUKS, because you explained it a lot better
than the official docs did. |
Well thank you. My intentions throughout this, besides garnering experience personally and encrypting my own machines, was to write a definitive guide to the plethora of methods available to use. My friend and I were going to collaborate with our findings on performance, ease, implementation, etc at our LUG in Nashua as a starting ground for this. Right now the information on encryption is too far spread out and contradictory because a lot of the sites are outdated. I firmly believe everyone should be using some encryption.
| hnaparst wrote: | | Encrypting / scares me. |
It's a lot to get into a first but it is worth it and very rewarding once you start to experience successes.
| hnaparst wrote: | | I suppose you had to make an initrd in order to do this? |
Yes I had to make an initrd for a full / encryption scheme.
| hnaparst wrote: | | What is your thinking about why you should encrypt / and not just /home swap and use tmpfs? |
I was thinking that being able to access my binaries without cracking the encryption scheme was the weakest point in my system. They could drop in their own modules and edit things till they could obtain the keys/passwrds to break it if they got my laptop long enough to do the work. Some of my reasoning was paranoia, some of it was motivated by the challenge of doing it. Obviously only encrypting the sections containing personal data wll improve your performance some too.
| hnaparst wrote: | I opted for a simpler solution because it seems to be what Gentoo supports,
and that is usually good enough. |
I have to agree with you here. Encrypting individual partitions like /home, /temp and swap is EXTREMELY easy using dmcrypt luks and the unstable baselayout. The gentoo developers did a superb job with /etc/conf.d/cryptfs. It is a lot less work to use this method. Hopefully, myself and others can reduce the work for full root encryption though.
If you have any more questions or input, feel free to post or message me. |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1838
Location: PB, Germany
|
| Posted: Sun Feb 19, 2006 12:06 pm Post subject: Re: automatic mounting of LUKS /home partition |
|
|
| hnaparst wrote: | | there is actually another command "luksClose" which is not explained either. |
luksClose deletes the mapper device /dev/mapper/_xxx which holds the decrypted blockdevice. You have to Open it again and provide one of the passphrases.
| hnaparst wrote: | | how to make this happen automatically at boot time?? |
Automatically mount dm-crypt encrypted home with pam_mount explains how to open the encrypted home partition with the user password only automatically.
The Howto doesn't explain LUKS. But according to the /etc/security/pam_mount.conf comments, pam_mount should be LUKS aware (so far I didn't succeed either, but later about that..): | Code: | # Note that pam_mount is LUKS (http://luks.endorphin.org) aware. To
# use luks, you need to have cryptsetup-luks (get it at
# http://luks.endorphin.org/dm-cryp) installed. A config line would be
#volume user1 crypt - /dev/yourpartition /yourmountpoint - - -
# and cryptsetup will be told to read cypher/keysize/etc. from the luks-header. |
| hnaparst wrote: | 1) Please describe the relationship between the "master key" and the other keys that are added
with luksAddKey. For instance, does one generally need both the master key and the second key
in order to access the data? Can you access the data with just the second key? Does each user
have a different key? Can they access each other's data? I know they can delete each other's keys.
That seems weird. |
The master key will be encrypted by your passphrase. The masterkey is never stored in plain text. Every slot contains a version of the masterkey encrypted by the passphrase of that slot. But I don't know where the masterkey comes from or wether it is generated randomly. You can access your data with every passphrase. To add another passphrase you have to provide one of the registered passphrases. You can delete every passphrase slot. There is nothing like a master passphrase. This I know from the LUKS-homepage
| hnaparst wrote: | 2) What is the relationship between a user's Linux password and the luks Key? Would it be
possible to have each user's password also be a luks key? Is this a good idea? |
There's no relationship between LUKS passphrase and huser password. The goal of the pam_mount Howto is to achieve that. Instead of a passphrase you take a key-file which is stored on another partition. But obviously not in plain text but ssl encrypted. This encryption is done with the user password. pam_mount reads the key-file decrypted by your user password and opens+mounts the home partition. In order to change a user password you only have to reencrypt the keyfile, manually or with the tool passwdehd
| hnaparst wrote: | 3) What does luksClose actually do? What does luksOpen actually do? It appears necessary to
"open" the device before mounting it. Why? Why is it necessary to unmount before closing? |
luksOpen makes the binding between encrypted /dev/hda3 and the clear /dev/mapper/_dev_hda3. Everyone (who has physical access of course, that is what we talk about) is able to mount that device. Therefore the usual way is alwas: luksOpen -> mount , umount -> luksClose
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1838
Location: PB, Germany
|
| Posted: Sun Feb 19, 2006 12:39 pm Post subject: |
|
|
To my problem: I've had the pam_mount solution without LUKS working. I would prefer LUKS. LUKS is working manually, but it doesn't accept the passphrase given from pam_mount. I have a hunch that maybe LUKS doesn't read properly from pipe, while reading from file works. Take a look at that: | Code: | home # echo $KEY >cache
home # cryptsetup -c aes-cbc-essiv:sha256 luksFormat /dev/hda5 cache
WARNING!
========
This will overwrite data on /dev/hda5 irrevocably.
Are you sure? (Type uppercase yes): YES
home # cryptsetup -d cache luksOpen /dev/hda5 _dev_hda5
key slot 0 unlocked.
home # cryptsetup remove _dev_hda5
home # echo $KEY |cryptsetup luksOpen /dev/hda5 _dev_hda5
Command failed: No key available with this passphrase. |
And of course, I found a quite old bug report . I opened a new one.
But for now it seems that only cryptsetup-luks is affected. cryptsetup works fine with pam_mount.
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1838
Location: PB, Germany
|
| Posted: Tue Feb 21, 2006 10:05 pm Post subject: |
|
|
I got an answer from the mailinglist: | Quote: | > # echo $KEY >cache
Try "echo -n $KEY > cache"
as noted in the man page, password reading from a file descriptor are
chopped of after \0 or \n. Hence, you have
$ echo kuh | hexdump -C
00000000 6b 75 68 0a |kuh.|
00000004
as key, but read
$ echo -n kuh | hexdump -C
00000000 6b 75 68 |kuh|
00000003
from the terminal/file descriptor. There is no way to enter a line break
via terminal or an fd. You have to set a key without a line break to be
able to open a LUKS partition. A key including \0 or \n must be
delivered to cryptsetup as binary key via "-d".
Please forward this message to the respective bug/forum threads. |
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
batistuta
Veteran
Joined: 29 Jul 2005
Posts: 1384
Location: Aachen
|
| Posted: Wed Jan 24, 2007 4:15 pm Post subject: |
|
|
interesting discussion.... few questions 
- Do you guys know if the latest ~x86 pam_mount supports luks now?
- How many passwords slots are in LUKS table? The documentation says that there is a limit, but it doesn't say how many
- According to what paoleela said, pam_mount doesn't use a key slot but rather a different file. Does this mean that a limit in the number of slots wouldn't be an issue for large userbase systems?
Just for knowledge
- Let's say that we have a box with 10 users (i.e. a company) all mounting LUKS /home with pam_mount. Then this person leaves the company. Is there any way that he could have "stolen" the master key given (a- he was admin, b- he was just a normal user)?
Any tutorial on encrypting / ?
Thanks |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1838
Location: PB, Germany
|
| Posted: Wed Jan 24, 2007 7:45 pm Post subject: |
|
|
- pam_mount now supports LUKS at least for my version: sys-libs/pam_mount-0.17-r1. Take the sunrise overlay, that offers a new pam_mount.
- I have in mind something around 9 or 10 keyslots.
- Every key can delete or overwrite the other keys, but cannot see the passphrase of any other slot.
Greetings to Aachen!
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770
Last edited by Massimo B. on Thu Jan 25, 2007 9:05 am; edited 1 time in total |
|
| Back to top |
|
|
batistuta
Veteran
Joined: 29 Jul 2005
Posts: 1384
Location: Aachen
|
| Posted: Thu Jan 25, 2007 7:52 am Post subject: |
|
|
My question was based on something you wrote:
| Quote: | | The goal of the pam_mount Howto is to achieve that. Instead of a passphrase you take a key-file which is stored on another partition. But obviously not in plain text but ssl encrypted. This encryption is done with the user password. pam_mount reads the key-file decrypted by your user password and opens+mounts the home partition. |
So does this mean that the master key to the partition is encrypted with the login password and stored inside a file in some partition? Or does pam_mount use this file, encrypted with the user login passwd, as a second key to then decrypt a master key in a LUKS slot, and this third key in turn opens the partition? In the first case, the only difference is the location of the key (file or LUKS slot). I would assume the file is in some location not accessible to the user otherwise he could get the key. But this approach has a loopwhole, that any other user could boot from a liveCD or via an ext3 driver from a Windows boot, access the key locations, steal the file, and decrypt it with his own password for future access if his account is later deleted. Or an external user could steal the file and run a dictionary attach on these files off-line.
Greeting to Bonn |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1838
Location: PB, Germany
|
| Posted: Thu Jan 25, 2007 9:13 am Post subject: |
|
|
As I said that was not about LUKS. That was before when I had usual cryptsetup. For better security I had a large keyfile encrypted with a small key (same as the user password) and connected to pam_mount. Actually LUKS does that on its own. It takes the keys to encrypt a big master key which no user need to know. Therefore changing the key is quick because only that master key has to be reencrypted, not the partition itself.
These things I remembered from my mind, not sure if it's completely correct. And I have to agree, the Luks documentation is a bit small compared to the importance of the project. At these times when I did my tests (it is running fine for months now without touching, for /home and also for some external usb and firewire devices; they are opened and mounted *if* they are connected at login) they told me to help making the docs better.
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
CodAv
Apprentice
Joined: 09 May 2004
Posts: 170
Location: Essen, Germany
|
| Posted: Thu Jan 25, 2007 12:11 pm Post subject: |
|
|
| batistuta wrote: | | - How many passwords slots are in LUKS table? The documentation says that there is a limit, but it doesn't say how many |
LUKS provides 8 key slots. You need to enter any one of them to open the partition. This enables you to change and revoke passphrases without re-encrypting the whole partition.
| batistuta wrote: | | - According to what paoleela said, pam_mount doesn't use a key slot but rather a different file. Does this mean that a limit in the number of slots wouldn't be an issue for large userbase systems? |
On a multi-user system, you probably don't want to stuff all user data in one encrypted container. Rather, you'd create a container for each user's home dir, which is mounted to /home/$USERNAME at login. The container doesn't have to be a partition, you can LUKS format a simple file and mount it via the loop device. One drawback of this method is that you need to allocate a lot of disk space for the container files, even if a user has only a few kilobytes of data in his homedir.
| batistuta wrote: | Just for knowledge
- Let's say that we have a box with 10 users (i.e. a company) all mounting LUKS /home with pam_mount. Then this person leaves the company. Is there any way that he could have "stolen" the master key given (a- he was admin, b- he was just a normal user)? |
There are rumours that it is possible to access the memory area storing the master key when a dm-crypt partition is mounted. As far is I know you only need to have just the rights of a local user to compromise the key. Again, to stay secure, every user should have his/her own LUKS container. As an "admin", which means he had root access to the machines, he could simply use a keylogger daemon to sniff the user's passwords.
_________________
Debian is available in three different versions: rusty, stale and broken. |
|
| Back to top |
|
|
batistuta
Veteran
Joined: 29 Jul 2005
Posts: 1384
Location: Aachen
|
| Posted: Thu Jan 25, 2007 1:01 pm Post subject: |
|
|
Is there no performance loss if using a loop device? I'm talking about a 30GB worth of data in my home partition. In any case, this approach doesn't scale too well... was LUKS never intender for enterprise solution or am I missing something? think about a samll company with 20 users. You can't have 20 LUKS slot, but neither 20 partitions or 20 loopback devices.
According to the docs, LUKS supports a keyfile as well. This was the steup I was refering to. Is this a stand-alone master key, or a key to decrypt a LUKS-slot key? |
|
| Back to top |
|
|
forrestfunk81
Guru
Joined: 07 Feb 2006
Posts: 567
Location: münchen.de
|
| Posted: Thu Jan 25, 2007 2:49 pm Post subject: |
|
|
| batistuta wrote: | | According to the docs, LUKS supports a keyfile as well. This was the steup I was refering to. Is this a stand-alone master key, or a key to decrypt a LUKS-slot key? |
A keyfile uses a further key slot.
My way:
| Code: |
# create a file containing some text
echo "aS?d2jfo305,qIjea_Efajs34EflkZ-jas@lk,.-fjPqeJrsA2klfjMd§y+#xco8jvyBx?:c" >> /home/XX/.crypt.key
# encrypt the content
dd if=/dev/random of=/home/XX/.crypt.key count=1
# add this key file
cryptsetup luksAddKey /dev/sdaX /home/XX/.crypt.key
# open partition using the key file
cryptsetup luksOpen /dev/sdaX /dev/mapper/crypt-XX -d /home/XX/.crypt.key
|
then save the key file on your truecrypt encoded usb stick - paranoia ftw 
greetings
_________________
# cd /pub/
# more beer |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
