Debian Live encrypted persistence

[/dev/null]

I'm trying to setup encrypted persistent partition for Debian Live.

I'm using custom build made this way:
lb_config -d sid -b hdd --interactive-shell
the only one additional package is cryptsetup.

Persistence works well but only when persistent partition is non-encrypted.
For encrypted partition - I've got a prompt for password and everything, but changes disappear after reboot.

I tried method with encrypted partition and persistence.conf file in it's root (inside the file there's "/ union", and partition has label "persistence")
and the method with image file(persistence.conf file is in the root of image file called persistence, which is inside encrypted partition.

boot parameters are: persistence and persistence-encryption=luks

What am I doing wrong?
Does encrypted persistence work for anyone here?

[dzz]

I never managed to, nor even heard of anybody who did, get Luks encryption working for persistence. I don't believe it actually works, If that's incorrect I too want to know the answer. I suspect what happens is, the persistence department gets opened but then lost further into the boot process.

The live-boot docs and man pages (squeeze) seem to say only AES is supported but I never tried that. Wheezy/sid docs refer to Luks but seem to be incomplete.

It is possible to use a "live-hook" initscript to activate a Luks /home partition or loopback file before login, that works for me. More details are posted at Refracta forums.

[pcalvert]

On what kind of drive is the persistent partition located?

Phil

[/dev/null]

@pcalvert
On the second partition of Debian Live pendrive

@dzz
Thank you for info. Bad news but still something. I will definitely check that hack.

Anyway here's one of my messages from Debian live mailing list. It points the moment in boot procedure when the possible bug occurs. Maybe someone more competent than me can make some use of it.

I checked /var/log/live/boot.log using debug as another boot parameter and I compared it to boot.log file extracted from another Debian Live pendrive on which persistent partition is NON-encrypted.
The interesting part is this:
At certain point of boot process all partitions are probed for filesystem label. For my NON-encrypted Debian Live it goes like this:

+ probe_for_fs_label live-rw home-rw persistence /dev/sdb2
+ local overlays dev
+ overlays=live-rw home-rw persistence
+ dev=/dev/sdb2
+ /sbin/blkid -s LABEL -o value /dev/sdb2
+ [ persistence = live-rw ]
+ /sbin/blkid -s LABEL -o value /dev/sdb2
+ [ persistence = home-rw ]
+ /sbin/blkid -s LABEL -o value /dev/sdb2
+ [ persistence = persistence ]
+ echo persistence=/dev/sdb2
+ result=persistence=/dev/sdb2

So as you can see my persistent partition label "persistence" matched one of the overlays: "persistence"



Now in the same place in boot.log file from Debian Live with encrypted partition it goes like this:

+ probe_for_fs_label live-rw home-rw persistence Loading /etc/boottime.kmap.gz /dev/mapper/sdb2
+ local overlays dev
+ overlays=live-rw home-rw persistence
+ dev=Loading
+ /sbin/blkid -s LABEL -o value Loading
+ [ = live-rw ]
+ /sbin/blkid -s LABEL -o value Loading
+ [ = home-rw ]
+ /sbin/blkid -s LABEL -o value Loading
+ [ = persistence ]
+ result=
+ [ -n ]

So it looks like the filesystem label is not set. But it is not true!
I double checked it:
I plugged the Debian live pendrive to my regular desktop Debian machine and run:
cryptsetup luksOpen /dev/sdb2 xxx (sdb2 is the luks-encrypted persistent partition)
e2label /dev/mapper/xxx
and the output is:
persistence

[kiyop]

I do not know if the initramfs file of your live debian accepts some kernel options which enable the feature you want; encrypted persistent pertition.
What is done at booting is written in an initramfs file (initrd.img or so).
If you expand it, you will see a file init and you can analyze it. It calls another scripts, which also are able to be analyzed.
Modification on the files may do a trick.
Good luck!

[/dev/null]

If you expand it, you will see a file init

I don't know exactly how to do it
there are 2 initramfs:
initrd1.img and initrd2.img
I guess I should mount them first to see what is inside? But mount command prompts for filesystem type, and I don't know it

Midnight Commander's F3 button seem to open it in mostly human readable form, but I suppose it's not the way that it should be done.

[kiyop]

If you expand it, you will see a file init

I don't know exactly how to do it
there are 2 initramfs:
initrd1.img and initrd2.img
I guess I should mount them first to see what is inside? But mount command prompts for filesystem type, and I don't know it

You can extract (expand) the contents inside initrd1.img into a newly generated directory such as "initramfs" by executing the following:

Code: Select all

mkdir initramfs && cd initramfs
gzip -dc PATH/TO/initrd1.img | cpio -i

You should change the above "PATH/TO/" to correct path. Both of its absolute path and its relative path is OK.
If you do not know "absolute path" and/or "relative path", refer http://en.wikipedia.org/wiki/Path_%28computing%29

[pcalvert]

@pcalvert
On the second partition of Debian Live pendrive

You should read these articles:
Solid State Drives And Encryption, A No-Go?
Seven Major Weaknesses with Software Encrypted USB Flash Drives

Phil

[dzz]

Already following that mailing list topic here, today the main man says it's on the TODO list and "patches welcome". So it doesn't work yet.

As far as I know a standard image has two kernel (one 486, one 686 or PAE) so 2x initrd. The problem probably is not in there.

The debug log shows what's going on but only as far as, apparently, the point where the mounts get transferred to the "real" FS (/lib/live/mounts/). Bash skills better than mine are needed to follow all of it. But your log snip does seem to show persistence being set at some point. What happens to it after, who knows.

cat /proc/mounts might give some clue, if anything beginning "/root/" is there, it didn't get moved properly and is no longer accessable. Another clue might be in /var/log/boot

BTW the initscript idea I mentioned is not actually a "hack", but a custom script, used with the existing live-hook mechanism provided for that purpose.

@pcalvert, thanks for those links, an interesting read. However a LUKS ext2 loopback file is probably about the best you can do for pen drive security (ext2 does less writes)

[pcalvert]

@pcalvert, thanks for those links, an interesting read. However a LUKS ext2 loopback file is probably about the best you can do for pen drive security (ext2 does less writes)

A pen drive with built-in encryption would be even better. Not all of them are compatible with Linux, though.

Phil

[fsmithred]

In squeeze, my way of dealing with this was to make a small, unencrypted home-rw and a large encrypted partition. The encrypted partition gets mounted after logging in, and I keep my files there. Things like ~/.mozilla, ~/.gnupg and ~/.ssh are symlinked to the encrypted partition.

In wheezy, I'm using dzz's scripts, and I'm very happy with the way they work. I'm using a second partition instead of a loopback file for persistence. See this thread - http://refracta.freeforums.org/snapshot ... -t182.html

Put the scripts in /live/hooks, edit the boot line, and you're good to go. No need for persistence.conf or special labels, no need for rebuilding the initramfs. (Is that last part still true if you use a loopback file?)

BTW, the label on your persistence partition is not showing up, because the label is on the filesystem inside the encrypted volume. The system can't see the label until the encrypted volume is opened.

CAVEAT: I just noticed that I'm posting in the Beginners section, and this might not be beginners material. END CAVEAT
Be brave. Go for it. It's not difficult.

[dzz]

A persistence loopback file must be in a writable location. Because the live-media partition gets mounted RO that normally means, in a second partition.

Same goes with the luks-home "hook" method (which does not actually use persistence but replaces /home/user with a writable, custom one)

It's (unofficially) possible to hack live-boot scripts in the initrd to use different mount options though...

A loopback can be more flexible than an entire partition for persistence, e.g. you can use the partition for other things as well or even have multiple loopbacks for different purposes.

Beginners (and others who don't need extra capability) will find the ext2 dedicated partition method simpler.

[/dev/null]

Thank you all. I'll try to make it work and let you know about the results.

[haylo]

I have tested it and it works with lb from sid.

If you want help, then come on IRC @ irc.oftc.net #debian-live , and ask for help. The people there will be glad to assist you (including me)

[haylo]

no need for any "hacks"
it works, just takes a lot of research