FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 05-18-2010, 07:38 PM
Eray Aslan
 
Default Kernel upgrade and now LUKS failure

On Tue, May 18, 2010 at 08:57:58PM +0200, Stefan G. Weichinger wrote:
> Am 18.05.2010 19:57, schrieb Jan Engelhardt:
> Ok, I see. So my current setup with one disk only and SSL-generated
> keyfile does not add security but flexibility (being able to switch
> passwords more quickly).

Keep the keyfile in a usb-stick if you can. Decrypting the hard disk
will require both the usb-stick and the password, i.e. two factor
authentication.

--
Eray
 
Old 05-18-2010, 08:06 PM
Jan Engelhardt
 
Default Kernel upgrade and now LUKS failure

On Tuesday 2010-05-18 21:33, Stefan G. Weichinger wrote:
>Am 18.05.2010 20:57, schrieb Stefan G. Weichinger:
>
>> On the other hand I would like to get that done right, sure.
>>
>> Any howto without pmt-ehd that would keep me safe from newlines etc
>> (btw. there were NO newlines in that hexdump-output)?
>
>Created a new encrypted LV and used "--key-file=-" as mentioned in:
>
>http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt
>
>Still no success with 2.x ...

Debugging preexisting containers is hard (because people usually don't
share that.)

Since you are starting with a blank one, I would love to see your
failing testcase -- i.e. sequence of shell commands to trigger the
unanticipated behavior, such as the existing testcases in
src/t-crypt:

echo that | openssl whatever
cryptsetup luksFoo,Format,Open that.
mkfs
cryptsetup luksClose
mount.crypt -o [...]

It does not need to follow t-crypt's style, just the sequence alone
is good.
 
Old 05-18-2010, 08:17 PM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure

Am 18.05.2010 22:06, schrieb Jan Engelhardt:
>
> On Tuesday 2010-05-18 21:33, Stefan G. Weichinger wrote:
>> Am 18.05.2010 20:57, schrieb Stefan G. Weichinger:
>>
>>> On the other hand I would like to get that done right, sure.
>>>
>>> Any howto without pmt-ehd that would keep me safe from newlines
>>> etc (btw. there were NO newlines in that hexdump-output)?
>>
>> Created a new encrypted LV and used "--key-file=-" as mentioned
>> in:
>>
>> http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt
>>
>>
>>
Still no success with 2.x ...
>
> Debugging preexisting containers is hard (because people usually
> don't share that.)
>
> Since you are starting with a blank one, I would love to see your
> failing testcase -- i.e. sequence of shell commands to trigger the
> unanticipated behavior, such as the existing testcases in
> src/t-crypt:
>
> echo that | openssl whatever cryptsetup luksFoo,Format,Open that.
> mkfs cryptsetup luksClose mount.crypt -o [...]
>
> It does not need to follow t-crypt's style, just the sequence alone
> is good.


I saved my history, unfortunately only the last steps were kept, but I
am able to reconstruct:

The block-device is /dev/VG01/sgwcrypt ...

#I tried a more complicated KEY
KEY=`head -c 79 /dev/urandom`

# avoid newline here
echo -n $KEY | openssl aes-256-cbc > /etc/security/super.key

# format it, using "--keyfile=-" as mentioned in bugs ...
openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
--key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat
/dev/VG01/sgwcrypt

# open it
openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
--key-file=- luksOpen /dev/VG01/sgwcrypt newhome

# create fs on the open luks-volume
mkfs.ext3 /dev/mapper/newhome

# mount the new fs
mount /dev/mapper/newhome /mnt/gschwind

all this worked OK so far, but not with pam_mount.

OK?

Stefan
 
Old 05-18-2010, 09:16 PM
Jan Engelhardt
 
Default Kernel upgrade and now LUKS failure

yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote:
>
>I saved my history, unfortunately only the last steps were kept, but I
>am able to reconstruct:
>
>The block-device is /dev/VG01/sgwcrypt ...
>
>#I tried a more complicated KEY
>KEY=`head -c 79 /dev/urandom`

Well, I'm not going to blame you yet, but the shell is pretty
binary-unsafe -- and you have just invoked that voodoo again.

# head -c79 /dev/urandom >t-crypt.ukey;
hexdump -C <t-crypt.ukey;
KEY=$(cat t-crypt.ukey);
echo -n "$KEY" | hexdump -C;
echo -n "$KEY" | wc;
00000000 a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05 e7 |....O..7f.. -..|
00000010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e |.^].]..*..-A".f.|
00000020 b0 a3 1d 41 1e 23 1d 00 f8 b2 b2 bc 34 28 94 fe |...A.#......4(..|
00000030 ba 0f 45 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.........^H..|
00000040 17 a8 75 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..u....z./.d.:.|
0000004f

00000000 a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd |....O.7f.. -...|
00000010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e b0 a3 |^]]..*..-A".f...|
00000020 1d 41 1e 23 1d f8 b2 b2 bc 34 28 94 fe ba 0f 45 |.A.#.....4(....E|
00000030 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f 17 a8 75 |.........^H....u|
00000040 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |....z./.d.:.|
0000004c
0 2 76

So what was once 79 bytes has been reduced to 76 by means of the $()
or backtick operator.

Not a problem for the crypto utilities per se, but I wanted to point out
that you are effectively only having a 76-long key here. The chance to
get a key shorter than the requested 79 is 27%.

># avoid newline here
>echo -n $KEY | openssl aes-256-cbc > /etc/security/super.key
>
># format it, using "--keyfile=-" as mentioned in bugs ...
>openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
>--key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat
>/dev/VG01/sgwcrypt
>
># open it
>openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
>--key-file=- luksOpen /dev/VG01/sgwcrypt newhome

Turns out cryptsetup has yet another oddity. With LUKS, --key-file=- is
moot. Instead....

[fkey is the unencrypted one]

# cryptsetup luksFormat /dev/loop94 t-crypt.fkey &&
cryptsetup --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey
Key slot 0 unlocked.


And you thought that doc/bugs.txt described all cryptsetup CLI oddities.

*facepalm*

ANYWAY.


If I proceed with this luks container now, all succeeds:

# mkfs.ext4 /dev/mapper/x94
mke2fs 1.41.9 (22-Aug-2009)
...
# cryptsetup remove x94

First, let's see if raw passthrough works:

# ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94 /mnt
command: 'readlink' '-fn' '/dev/loop94'
command: 'readlink' '-fn' '/mnt'
mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name
command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt'
# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop94 62465 5365 53875 10% /mnt
# PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt


Now the openssl-encrypted file:

# ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt
command: 'readlink' '-fn' '/dev/loop94'
command: 'readlink' '-fn' '/mnt'
Password:
mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name
command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt'
# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop94 62465 5365 53875 10% /mnt


Match?
 
Old 05-18-2010, 09:49 PM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure

Am 18.05.2010 23:16, schrieb Jan Engelhardt:
> yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote:
>>
>> I saved my history, unfortunately only the last steps were kept,
>> but I am able to reconstruct:
>>
>> The block-device is /dev/VG01/sgwcrypt ...
>>
>> #I tried a more complicated KEY KEY=`head -c 79 /dev/urandom`
>
> Well, I'm not going to blame you yet, but the shell is pretty
> binary-unsafe -- and you have just invoked that voodoo again.
>
> # head -c79 /dev/urandom >t-crypt.ukey; hexdump -C <t-crypt.ukey;
> KEY=$(cat t-crypt.ukey); echo -n "$KEY" | hexdump -C; echo -n
> "$KEY" | wc; 00000000 a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05
> e7 |....O..7f.. -..| 00000010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41
> 22 e7 66 0e |.^].]..*..-A".f.| 00000020 b0 a3 1d 41 1e 23 1d 00 f8
> b2 b2 bc 34 28 94 fe |...A.#......4(..| 00000030 ba 0f 45 11 b5 c6
> d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.........^H..| 00000040 17 a8 75
> af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..u....z./.d.:.| 0000004f
>
> 00000000 a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd
> |....O.7f.. -...| 00000010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66
> 0e b0 a3 |^]]..*..-A".f...| 00000020 1d 41 1e 23 1d f8 b2 b2 bc 34
> 28 94 fe ba 0f 45 |.A.#.....4(....E| 00000030 11 b5 c6 d8 a1 ca c2
> ec 08 5e 48 d4 7f 17 a8 75 |.........^H....u| 00000040 af ef ef f1
> 7a 0f 2f bf 64 c2 3a 9c |....z./.d.:.| 0000004c 0
> 2 76
>
> So what was once 79 bytes has been reduced to 76 by means of the $()
> or backtick operator.
>
> Not a problem for the crypto utilities per se, but I wanted to point
> out that you are effectively only having a 76-long key here. The
> chance to get a key shorter than the requested 79 is 27%.
>
>> # avoid newline here echo -n $KEY | openssl aes-256-cbc >
>> /etc/security/super.key
>>
>> # format it, using "--keyfile=-" as mentioned in bugs ... openssl
>> aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
>> --key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat
>> /dev/VG01/sgwcrypt
>>
>> # open it openssl aes-256-cbc -d -in /etc/security/super.key |
>> cryptsetup -v --key-file=- luksOpen /dev/VG01/sgwcrypt newhome
>
> Turns out cryptsetup has yet another oddity. With LUKS, --key-file=-
> is moot. Instead....
>
> [fkey is the unencrypted one]
>
> # cryptsetup luksFormat /dev/loop94 t-crypt.fkey && cryptsetup
> --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey Key slot 0
> unlocked.
>
>
> And you thought that doc/bugs.txt described all cryptsetup CLI
> oddities.
>
> *facepalm*
>
> ANYWAY.
>
>
> If I proceed with this luks container now, all succeeds:
>
> # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... #
> cryptsetup remove x94
>
> First, let's see if raw passthrough works:
>
> # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94
> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
> '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as
> dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt'
> # df /mnt Filesystem 1K-blocks Used Available Use%
> Mounted on /dev/loop94 62465 5365 53875 10%
> /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt
>
>
> Now the openssl-encrypted file:
>
> # ./mount.crypt -vo
> keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94
> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
> '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using
> _dev_loop94 as dmdevice name command: 'mount' '-n'
> '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem
> 1K-blocks Used Available Use% Mounted on /dev/loop94
> 62465 5365 53875 10% /mnt
>
>
> Match?

Frankly: dunno ;-)
Yes, I am able to follow and understand in general so far ... but ...

Assuming that "I am too stupid": Where is the how-to-do-it?

So far the only thing I really understood "You are doing it wrong".

But where is the "Do it this way and you are safe" ?

I wouldn't post here if I were competent enough to know all these details.

Concerning encryption I am at the USER-level, you know for sure ;-)

Just trying to feed back my problems to maybe detect bugs or my mistakes.

Stefan
 
Old 05-18-2010, 10:23 PM
Jan Engelhardt
 
Default Kernel upgrade and now LUKS failure

On Tuesday 2010-05-18 23:49, Stefan G. Weichinger wrote:

>> # ./mount.crypt -vo
>> keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94
>> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
>> '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using
>> _dev_loop94 as dmdevice name command: 'mount' '-n'
>> '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem
>> 1K-blocks Used Available Use% Mounted on /dev/loop94
>> 62465 5365 53875 10% /mnt
>>
>> Match?
>
>Frankly: dunno ;-)
>Yes, I am able to follow and understand in general so far ... but ...

Right now it's more a case of "let's do it and compare results"
than having to thoroughly understand when and where cryptsetup
chops off a byte and pads another.

That went fine, up to

># mount the new fs
>mount /dev/mapper/newhome /mnt/gschwind
>all this worked OK so far, but not with pam_mount.
>OK?

OK, but don't stop there. pam_mount really just ultimatively runs
mount.crypt; and it tells you that it does by means of syslog
(with enabled debug=1 of course).

command: 'mount.crypt' '-ofsk....

And that is what you can run from shell, which eliminates
pam_mount from the path and only leaves the usual suspects.

Keep on it, marine!


>Assuming that "I am too stupid": Where is the how-to-do-it?
>So far the only thing I really understood "You are doing it wrong".
>But where is the "Do it this way and you are safe" ?

http://archives.gentoo.org/gentoo-user/msg_e80d6e5a662b7595a2a8a70a0fa166dd.xml
was basically it: pmt-ehd and you're safe. Short of the current
...missing feature though, mentioned in that same mail.
 
Old 05-20-2010, 10:25 AM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure

Am 19.05.2010 00:23, schrieb Jan Engelhardt:

> OK, but don't stop there. pam_mount really just ultimatively runs
> mount.crypt; and it tells you that it does by means of syslog (with
> enabled debug=1 of course).
>
> command: 'mount.crypt' '-ofsk....

Sorry, I don't see that in my logs (yep, debug=1).


May 20 12:18:03 enzo slim: pam_mount(pam_mount.c:364): pam_mount 2.1:
entering auth stage
May 20 12:18:03 enzo slim: pam_mount(pam_mount.c:552): pam_mount 2.1:
entering session stage
May 20 12:18:03 enzo slim: pam_mount(misc.c:38): Session open: (uid=0,
euid=0, gid=0, egid=0)
May 20 12:18:03 enzo slim: pam_mount(mount.c:196): Mount info:
globalconf, user=sgw <volume fstype="crypt" server="(null)"
path="/dev/mapper/VG01-crypthome" mountpoint="/home/sgw"
cipher="aes-cbc-plain" fskeypath="/etc/security/verysekrit.key"
fskeycipher="aes-256-cbc" fskeyhash="md5"
options="data=journal,commit=15" /> fstab=0
May 20 12:18:03 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
euid=0, gid=0, egid=0)
May 20 12:18:03 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
(uid=0, euid=0, gid=0, egid=0)
May 20 12:18:12 enzo slim: pam_mount(mount.c:64): Errors from underlying
mount program:
May 20 12:18:12 enzo slim: pam_mount(mount.c:68):
crypt_activate_by_passphrase: Operation not permitted
May 20 12:18:14 enzo slim: pam_mount(pam_mount.c:520): mount of
/dev/mapper/VG01-crypthome failed
May 20 12:18:14 enzo slim: pam_mount(misc.c:38): set_myuid<pre>: (uid=0,
euid=0, gid=0, egid=0)
May 20 12:18:14 enzo slim: pam_mount(misc.c:38): set_myuid<post>:
(uid=0, euid=0, gid=0, egid=0)
May 20 12:18:15 enzo slim: pam_mount(pam_mount.c:440): pmvarrun says
login count is 1
May 20 12:18:16 enzo slim: pam_mount(pam_mount.c:642): done opening
session (ret=0)
May 20 12:18:16 enzo slim: pam_mount(pam_mount.c:115): Clean global
config (0)
May 20 12:18:16 enzo slim: pam_mount(pam_mount.c:132): clean system
authtok=0x80bdac0 (0)



> And that is what you can run from shell, which eliminates pam_mount
> from the path and only leaves the usual suspects.
>
> Keep on it, marine!

I try ;-) *sigh*

Stefan
 
Old 05-20-2010, 01:40 PM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure

Am 20.05.2010 12:25, schrieb Stefan G. Weichinger:
> Am 19.05.2010 00:23, schrieb Jan Engelhardt:
>
>> OK, but don't stop there. pam_mount really just ultimatively runs
>> mount.crypt; and it tells you that it does by means of syslog (with
>> enabled debug=1 of course).
>>
>> command: 'mount.crypt' '-ofsk....
>
> Sorry, I don't see that in my logs (yep, debug=1).

debug=2 didn't show anything new, btw.

--

Trying pmt-ehd for a change:

# pmt-ehd -f /dev/VG01/sgwcrypt -p /etc/security/sgwcrypt.enc -h md5 -D
-s 25000

Creating a new container at /dev/VG01/sgwcrypt
/dev/VG01/sgwcrypt is a symlink and points to ../dm-2
Do you really want to overwrite /dev/VG01/sgwcrypt? (y/n)
y
Writing random data to container
Password:
Reenter password:
Using openssl cipher "aes-256-cbc" and hash "md5"
ehd(crypto-dmc.c:144): Using _dev_VG01_sgwcrypt as dmdevice name
crypt_activate: No such file or directory

Oh my ...
 
Old 05-21-2010, 08:24 PM
Daniel Troeder
 
Default Kernel upgrade and now LUKS failure

On 05/18/2010 07:57 PM, Jan Engelhardt wrote:
>
> On Tuesday 2010-05-18 18:56, Stefan G. Weichinger wrote:
>>
>>>> Do you know any howto where it is done "the right way"?
>>>
>>> The right and easy way is to just use the supplied pmt-ehd(8) tool,
>>> which works both interactively and non-interactively, depending on
>>> whether it's called with enough arguments or not, so there's something
>>> for everybody's flavor.
>>> It does not do LUKS yet as of pam_mount 2.2, though. Guess my
>>> todo list gets longer..
>>
>> :-)
>>
>> But given the fact that I store the key on the same hard-disk with the
>> shadowed user-pw I could also leave that openssl-part straight away,
>> correct?? seems the same level of (in)security to me ...
>
> Yes. The point of keyfiles is to be able to change the password on
> a volume.
>
> Without a keyfile, a crypto program would take the password, hash it
> somehow, and you get your AES key. Changing the password means having
> a different AES key, meaning decrypting the disk will yield a
> different result. In other words, changing the password would require
> at least reading the old data, reencrypting it and writing it again.
> Takes time.
>
> With a keyfile, you retain the same AES key all the time, and encrypt
> the AES key itself - reencrypting the AES key is quick, as it's
> only some xyz bits, not terabytes.

That's not true for LUKS. This is one of the nice things about it:
Multiple keys can be used on a volume, and it is possible to change the
passwords in a safe way. (You have 8 "key slots", each can be used to
decrypt the volume. To change a PW use a new slot, then remove the old
one.) The trick here is that LUKS does by itself safely, what you are
trying to do with the SSL-key in a hackish way (no offense). The key
setup scheme is a modified TKS1 (nice Paper:
http://clemens.endorphin.org/TKS1-draft.pdf - read section 2 "Two Level
Encryption") which uses the keys in the key slots to encrypt a master
key which is used to encrypt the volume. So the only key(s) you ever
change is the key(s) encrypting the master key.

LUKS really does by itself already, what you are doing

So I'm pretty sure, that it is safer to use the LUKS key setup (that has
been peer-reviewed by security experts), than a self written shell script.

Bye,
Daniel


--
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887
 

Thread Tools




All times are GMT. The time now is 12:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org