Can't mount an encrypted container after reboot

English Install/Boot/Login
#1

I made an encrypted file container using YaST’s partitioner. It mounted fine and I was able to use it. Ever since I rebooted, I can’t anymore.
I’m not sure what settings to tell you about. This is the relevant line in /etc/fstab:

/dev/mapper/cr_prot  /mnt/thprot          ext4       loop,noauto,acl,user_xattr,nofail 0 0

When I run

mount /mnt/thprot

I get “/dev/mapper/cr_prot: No such file or directory”.
Maybe the results from /etc/init.d/boot.crypto start are relevant

cr_prot                                                                                                                                                                                   unused

And /etc/init.d/boot.crypto start

Activating crypto devices using /etc/crypttab ... 
cr_prot                                                                                                                                                                                   skipped

Maybe you want to see my /etc/crypttab

cr_prot         /mnt/prot            none       noauto

I’ll bet this is relevant from my /var/log/messages:

Nov 10 19:56:46 bootsie kernel:   221.989589] padlock: VIA PadLock Hash Engine not detected.
Nov 10 19:56:46 bootsie modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.37.6-24-desktop/kernel/drivers/crypto/padlock-sha.ko): No such device

Looking back in the log, it seems that those padlock error messages have coincided w/this problem.
I guess that’s it. I’m running openSUSE 11.4 64-bit

#2

I have never used containers, so I could be mistaken here. But I think your “noauto” in “/etc/crypttab” is what is telling the startup scripts to ignore that container. The “noauto” in “fstab” should be okay, as that only says to not automatically encrypt.

Maybe it is correct to ignore the container on startup, because otherwise someone would have to provide the key.

The second of those two messages can be ignored. It just means that your processor does not contain special support for crypto. The chances are that the first of the two messages is due to the same thing.

I’m not quite clear on what you are trying to do here. If you want to provide the key during boot, then remove the “noauto” from “crypttab” (replace with “none”). If you want to provide the key and decrypt at a later time then


man crypttab

gives you the command to activate (decrypt) that container. (Search for the string “noauto” in the man page output - probably just type “/noauto” without the quotes while reading that man page).

#3

On 2012-11-11 02:36, PenguinLust wrote:
>
> I made an encrypted file container using YaST’s partitioner.

OS version? Ah, 11.4 you say at the end. Ok.

> Code:
> --------------------
> /dev/mapper/cr_prot /mnt/thprot ext4 loop,noauto,acl,user_xattr,nofail 0 0
> --------------------

> Maybe the results from /etc/init.d/boot.crypto start are relevant
>
> Code:
> --------------------
> cr_prot unused
> --------------------

I would like to see the command as well, not the edited version. Because
you apparently use the same command twice and get different results - so
you are NOT using the same command as you said.

>
> And /etc/init.d/boot.crypto start
>
> Code:
> --------------------
> Activating crypto devices using /etc/crypttab …
> cr_prot skipped
> --------------------

I want to see it like this:


minas-tirith:~ # rccrypto start
Activating crypto devices using /etc/crypttab ...
cr_sysdta                                        skipped
minas-tirith:~ #

Maybe you want to see my /etc/crypttab

Code:

cr_prot         /mnt/prot            none       noauto

It is unusual (and confusing) to have the file and the mount point in
the same directory.

I’ll bet this is relevant from my /var/log/messages:

Code:

Nov 10 19:56:46 bootsie kernel:   221.989589] padlock: VIA PadLock Hash Engine not detected.

Nov 10 19:56:46 bootsie modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.37.6-24-desktop/kernel/drivers/crypto/padlock-sha.ko): No such device

Looking back in the log, it seems that those padlock error messages
have coincided w/this problem.

No, the error is irrelevant. Probably the kernel tries to enable certain
kind of hardware encryption (my guess) and fails because you don’t have
that hardware. Just ignore that message (unless somebody knows how to
disable whatever triggers it - I don’t)

I guess that’s it. I’m running openSUSE 11.4 64-bit

Good! Because I’m using the same old version, and I can test the command
in my machine. If you were using a newer version I would be unable to
help very much. Try this other command instead:


rccrypto start cr_prot

This is a consequence of the “noauto” clause.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#4

On 2012-11-11 03:16, nrickert wrote:
> I have never used containers, so I could be mistaken here. But I think
> your “noauto” in “/etc/crypttab” is what is telling the startup scripts
> to ignore that container. The “noauto” in “fstab” should be okay, as
> that only says to not automatically encrypt.

The noauto in fstab is so that when fstab is read the system does not
try to mount it, because it is mounted instead by the script that asks
for the password.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#5

Wow! That was a lot of input for just a few hours.

It looks like that’s all I had to do to mount it on reboot. To answer your questions, what I want to do is not mount the file system on boot. I want to have it mount manually on my command. So this brings me to a couple of questions:

  1. If I do it this way, not storing the password in any script, the password will not be stored anywhere on my system, right? What algorithm does it use anyway?
  2. How reliable is this file system? How easy is it to damage above that of, say, ext4? How difficult is recovery? The last thing I want is to put all my precious data on it, then find that I lost it all before a hacker had a chance to access my harddrive.

So where do you think is a better place to store the container file?

Thanks for getting me up and running guys.

#6

On 2012-11-12 01:56, PenguinLust wrote:
>
> Wow! That was a lot of input for just a few hours.

:slight_smile:

> It looks like that’s all I had to do to mount it on reboot. To answer
> your questions, what I want to do is -not- mount the file system on
> boot. I want to have it mount manually on my command.

Same as I do.

> So this brings me
> to a couple of questions:
>
> - If I do it this way, not storing the password in any script, the
> password will not be stored anywhere on my system, right?

AFAIK, nowhere. Perhaps memory.

> What
> algorithm does it use anyway?

I do not really know. But:


> minas-tirith:~ # file /home/_var_data/data.crf
> /home/_var_data/data.crf: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: 57d5fbea-aced-44e2-982d-25aaa93

> - How reliable is this file system? How easy is it to damage above
> that of, say, ext4? How difficult is recovery? The last thing I want
> is to put all my precious data on it, then find that I lost it all
> before a hacker had a chance to access my harddrive.

I have been using it for several years, in several computers, and not a
problem yet. However, I have had filesystems corrupted and lost, and
that can happen to anyone, so it is important to keep a backup (I have a
procedure for writing encrypted DVDs, posted somewhere that I forgot where).

The script does a filesystem check prior to mounting it, if it is not
clean. However… that is in 11.4, in the following versions systemd is
taking charge, and I don’t trust it a bit.

> So where do you think is a better place to store the container file?

/data, or /var/data, for example. Mine is there, but it is a symlink to
the /home partition which in the laptop is bigger. In any case, not /mnt
which should be only mount points.

>
> Thanks for getting me up and running guys.

Welcome.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#7

Why are you saying you’ve not had a problem when you’ve had file systems lost? Are you saying that other kinds of file systems were lost, and that the container, therefore, has the same vulnerability?

#8

On 2012-11-12 19:46, PenguinLust wrote:

> Why are you saying you’ve not had a problem when you’ve had file
> systems lost? Are you saying that other kinds of file systems were lost,
> and that the container, therefore, has the same vulnerability?

I have had filesystem lost with every type of filesystem, of course, as
many people. No filesytem type is immune to problems. You need backups!
I had crashes with FAT as early as 1984 or there abouts. On reiserfs,
ext3, xfs, ntfs…

It is not a question of if they fail, but when.

And I also said that so far, I have not been hit with problems on
encrypted filesystems. Just chance, but my small experience is that they
are no more vulnerable than plain filesystems. When it happens I expect
to be royally f*2²^H^H^H^Hpained. >:-)

Is that clearer? :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#9

Yes it does, thanks. I’m aware that no file system is iron clad, but this file container is somewhat reminiscent of MS’s doublespace. That technology had the main logical drive as a mere file on a more concrete logical drive. Consequently, an event that would only cause you to lose, at worst, one file on a normal file system could lose you all your data on the compressed drive! That’s why I was worried about extra vulnerability using this container.

#10

With encrypted if it gets corrupted all is lost. With a normal file system there is a good chance that you can recover at least some of the data.

#11

I’m not sure that is really true.

With a normal file system in which the disk goes bad, you tend to lose whole sectors, but there is a lot that you can recover from sectors that are still readable.

With an encrypted file system, you are still reading the disk sector by sector, and encrypting sector by sector. So the same reasoning should apply.

The encryption is a bit more fragile because there is a luks header at the beginning which contains information about how the encryption is done. So if you happen to lose sectors that are part of the luks header, you might be out of luck on recovery. But, of course, there is a similar problem with a normal file system, in that there is control information there too. There are typically some backup superblocks which provide some redundancy. I’m not sure whether there is a backup luks header.

I agree that an encrypted file system is more fragile, in that there is more that can break. But some types of failure such as the loss of a few sectors in a non-critical part of the disk would probably look the same for an encrypted file system as for a normal file system.

The question raised was actually about a file system based on an encrypted container. And I guess that is more fragile still, since there is more to go wrong. A problem in the normal file system where the container file is located could already cause a problem. For example, a problem in the inode or directory entry used to access the container file would cause problems even if all sectors of that container file are intact.

As we go from a normal file system to an encrypted file system or an encrypted container, we increase the ways in which a system can fail. But I think your “all is lost” comment might be a little too pessimistic.

Good backup policies and practices are always the best protection, whether or not encryption is used.

#12

On 2012-11-13 04:36, PenguinLust wrote:

>> Is that clearer? :slight_smile:
>>
>
> Yes it does, thanks. I’m aware that no file system is iron clad, but
> this file container is somewhat reminiscent of MS’s doublespace. That
> technology had the main logical drive as a mere file on a more concrete
> logical drive. Consequently, an event that would only cause you to lose,
> at worst, one file on a normal file system could lose you all your data
> on the compressed drive! That’s why I was worried about extra
> vulnerability using this container.

Ah, good point.

I mostly use separate encrypted partitions, except on this laptop where
it is a loop mounted file. On the desktop machine I use loop files for
backup to dvd creation (several), which is an occasional usage.

However, I think that the container metadata (which is the fragile part)
is not touched. The kernel learns the location of the file and writes to
it, without really having to touch the metadata of the file.

On my desktop I have relatively frequent crashes (hibernation failure)
which means that all opened filesystems need an extensive fsck like
after a brutal power-off. No problems so far even on the encrypted
partitions. On the laptop, where I have a container as you name it, I
have less experience.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#13

Another question: what’s a reliable and clean way to make this thing user mountable? All the /dev/loops are not world-accessible, and if I make them so, it doesn’t last for very long and I get a ton of errors anyway:

Unlocking cr_DPN (/home/DPN)
WARNING!!! Possibly insecure memory. Are you root?
/dev/mapper/control: open failed: Permission denied
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
/dev/mapper/control: open failed: Permission denied
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.49 (2010-06-04)(compat) and kernel driver 
Cannot initialize device-mapper. Is dm_mod kernel module loaded?
cr_DPN...                                                                                                                                                                                 failed
#14

On 2012-11-15 03:26, PenguinLust wrote:
>
> Another question: what’s a reliable and clean way to make this thing
> user mountable? All the /dev/loops are not world-accessible, and if I
> make them so, it doesn’t last for very long and I get a ton of errors
> anyway:
>
> Code:
> --------------------
> Unlocking cr_DPN (/home/DPN)
> WARNING!!! Possibly insecure memory. Are you root?
> /dev/mapper/control: open failed: Permission denied
> /dev/mapper/control: open failed: Permission denied
> Failure to communicate with kernel device-mapper driver.
> /dev/mapper/control: open failed: Permission denied
> /dev/mapper/control: open failed: Permission denied
> Failure to communicate with kernel device-mapper driver.
> Incompatible libdevmapper 1.02.49 (2010-06-04)(compat) and kernel driver
> Cannot initialize device-mapper. Is dm_mod kernel module loaded?
> cr_DPN… failed
>
> --------------------

You fail to show what command you used.
Permissions in /dev do not hold because /dev is dynamic.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#15

The one you told me to use:

/sbin/rccrypto start cr_DPN
#16

On 2012-11-15 15:36, PenguinLust wrote:
>
> The one you told me to use:
>
> Code:
> --------------------
> /sbin/rccrypto start cr_DPN
> --------------------

It is preferable to show the command you type together with the output,
complete. Like this:


minas-tirith:~ # rccrypto status cr_sysdta
cr_sysdta  loop0 mapped mounted ]             running
minas-tirith:~ #

My suspicion is that you used “su” instead of “su -”. If you were really
root you would not have to type that “/sbin” path.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

#17

Actually, what I typed was “mountDPN” because that’s a script I wrote in my home-bin directory.

But what I’m trying to do is to mount this without being root. Is that feasible?

#18

On 2012-11-15 17:26, PenguinLust wrote:
>
> Actually, what I typed was “mountDPN” because that’s a script I wrote in
> my home-bin directory.
>
> But what I’m trying to do is to mount this with-out- being root. Is
> that feasible?

Not to my knowledge.

Maybe you could if done manually without the scripts or by defining
appropriate sudo entries (or a combination of both methods)

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))