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-06-2010, 04:24 PM
Daniel Troeder
 
Default Kernel upgrade and now LUKS failure.

On 05/05/2010 10:23 PM, Stefan G. Weichinger wrote:
> Am 05.05.2010 22:17, schrieb Stefan G. Weichinger:
>
>> Remember that I said: "I am not sure which HOWTO I followed" ?
>>
>> What if I didn't use aes-256-ecb?
You don't need to supplay that information to cryptsetup, it can
(should) autodetect it. To see that info for yourself run:
$ cryptsetup luksDump /dev/mapper/VG01-crypthome

> Yep. See pam_mount.conf.xml:
> It's "aes-256-cbc" in my case.
>
> I was now able to luksOpen and I have the decrypted device mounted.
Hooray


> Nice.
>
> So:
>
> the user-pw didn't change and the keyfile is OK.
>
> So why is pam_mount unable to mount it?
>
> I will now pull another backup and check/add fallback keys ;-)
There are interesting options in the cryptsetup-man page:
luksHeaderBackup and luksHeaderRestore... I think I'll add that to my
backup scripts


Bye,
Daniel


--
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887
 
Old 05-06-2010, 06:38 PM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure.

Am 06.05.2010 18:24, schrieb Daniel Troeder:
> On 05/05/2010 10:23 PM, Stefan G. Weichinger wrote:
>> Am 05.05.2010 22:17, schrieb Stefan G. Weichinger:
>>
>>> Remember that I said: "I am not sure which HOWTO I followed" ?
>>>
>>> What if I didn't use aes-256-ecb?
> You don't need to supplay that information to cryptsetup, it can
> (should) autodetect it. To see that info for yourself run:
> $ cryptsetup luksDump /dev/mapper/VG01-crypthome

But I always did when I followed your example.
Anyway, this part is solved now.

>> Yep. See pam_mount.conf.xml:
>> It's "aes-256-cbc" in my case.
>>
>> I was now able to luksOpen and I have the decrypted device mounted.
> Hooray

Yes :-)

Currently I run an unencrypted home on another LV.

>> Nice.
>>
>> So:
>>
>> the user-pw didn't change and the keyfile is OK.
>>
>> So why is pam_mount unable to mount it?
>>
>> I will now pull another backup and check/add fallback keys ;-)
> There are interesting options in the cryptsetup-man page:
> luksHeaderBackup and luksHeaderRestore... I think I'll add that to my
> backup scripts

Good idea.

The main question is still unanswered: Why does pam_mount not work
anymore with the given device/key ?

Should I file a bug?

S
 
Old 05-07-2010, 08:53 AM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure.

Am 06.05.2010 20:38, schrieb Stefan G. Weichinger:

> The main question is still unanswered: Why does pam_mount not work
> anymore with the given device/key ?

additional digging:

I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528366

where the poster tries the underlying mount.crypt call.

I did that as well and get:

# mount.crypt -v -o
fsk_cipher=aes-256-cbc,fsk_hash=md5,keyfile=/etc/security/verysekrit.key
/dev/VG01/crypthome /mnt/gschwind
command: 'readlink' '-fn' '/dev/VG01/crypthome'
command: 'readlink' '-fn' '/mnt/gschwind'
Password:
mount.crypt(crypto-dmc.c:144): Using _dev_dm_0 as dmdevice name
crypt_activate_by_passphrase: Operation not permitted


which is in fact the error pam_mount throws up :

pam_mount(mount.c:64): Errors from underlying mount program:
pam_mount(mount.c:68): crypt_activate_by_passphrase: Operation not permitted

Downgrade pam_mount from 2.1 to 2.0 ... same error.

But it works with pam_mount 1.33 !

I don't know which old bugs I reintroduce to my system by doing this ;-)

I think I am gonna file a bug for this now.

Stefan
 
Old 05-07-2010, 02:24 PM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure.

Am 07.05.2010 10:53, schrieb Stefan G. Weichinger:

> I think I am gonna file a bug for this now.

http://bugs.gentoo.org/show_bug.cgi?id=318865
 
Old 05-07-2010, 09:14 PM
"Stefan G. Weichinger"
 
Default Kernel upgrade and now LUKS failure.

Am 07.05.2010 16:24, schrieb Stefan G. Weichinger:
> Am 07.05.2010 10:53, schrieb Stefan G. Weichinger:
>
>> I think I am gonna file a bug for this now.
>
> http://bugs.gentoo.org/show_bug.cgi?id=318865

Aside from the potential bug:

As I store the "verysekrit.key" on the same hdd as the encrypted device
and use the rather simple shadowed password to decrypt that key ...
isn't that just plain stupid?

The overall security is just as good as my password.
Cracking it with john opens the key to decrypting the LUKS-volume ...

Yes, if I would store the key on another volume (stick or something) as
mentioned in that howto it would make sense but in my case ...

*scratches head* ;-)

Stefan
 
Old 05-10-2010, 04:48 PM
Daniel Troeder
 
Default Kernel upgrade and now LUKS failure.

On 05/07/2010 11:14 PM, Stefan G. Weichinger wrote:
> Am 07.05.2010 16:24, schrieb Stefan G. Weichinger:
>> Am 07.05.2010 10:53, schrieb Stefan G. Weichinger:
>>
>>> I think I am gonna file a bug for this now.
>>
>> http://bugs.gentoo.org/show_bug.cgi?id=318865
>
> Aside from the potential bug:
>
> As I store the "verysekrit.key" on the same hdd as the encrypted
> device and use the rather simple shadowed password to decrypt that
> key ... isn't that just plain stupid?
>
> The overall security is just as good as my password. Cracking it with
> john opens the key to decrypting the LUKS-volume ...
>
> Yes, if I would store the key on another volume (stick or something)
> as mentioned in that howto it would make sense but in my case ...
>
> *scratches head* ;-)
>
> Stefan
I prefer to encrypt my entire harddisk. Well - a hugh partition (excl.
only Windows and Solaris which I encrypt, then the decrypted
partition is used as a PV for LVM and all OS and partitions an in LVs.
This way I have to type in the password to decrypt the PV once, and all
LVs are decrypted. Then I have to use a second PW to login of course. As
all Linux destros support encrypted roots and LVM nowadays I have
Gentoo, Fedora and Ubuntu all in the same VG. The speed disadvantage is
small, as my CPU+RAM is so much faster than the HDD. But in terms of
security it's better to have everything encrypted, because it makes it
more difficult to manipulate your system to get the key (the kernel is
still unencrypted), and no possibly private information can be obtained
from /tmp and /var. I compile all needed modules into the kernel, so I
don't need to recreate my initrd for every new kernel.

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 07:21 AM.

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