LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian
User Name
Password
Debian This forum is for the discussion of Debian Linux.

Notices


Reply
  Search this Thread
Old 06-13-2018, 10:32 PM   #1
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware14.2 64-Bit Desktop, Devuan 2.0 ASCII Toshiba Satellite Notebook
Posts: 2,568

Rep: Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704
Encrypted swap hibernate part II


So as per documentation - https://help.ubuntu.com/community/En...s_and_Warnings - I am attempting this on a VM because if I screw up, it won't matter and as I expected I ran into issues and not sure what to do:

Click image for larger version

Name:	VirtualBox_Devuan_13_06_2018_22_23_15.png
Views:	22
Size:	97.3 KB
ID:	27895

Any clues would be helpful

-edit

After rebooting anyways, I still have a working VM, only this time when I am in root and do a swapon --summary , there is no output.

Last edited by Jeebizz; 06-13-2018 at 10:41 PM.
 
Old 06-26-2018, 08:33 PM   #2
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 231

Rep: Reputation: 42
Here I am assuming the last things you did are shown in the screenshot. I'm seeing a couple of things.

First, when you set up an encrypted partition by running "cryptsetup luksFormat ...", you are telling the cryptsetup program to prepare a LUKS header for a specific partition. This should be /dev/sdX and not /dev/dm-X. /dev/dm-X entries get created after "cryptsetup luksOpen ..." is run. Essentially you are double-LUKS'ing here.

Second, after you do get the partition properly "formatted", you need to manually set up swap space - this time on the 'dm' entry. You'll need to run, for example, "mkswap /dev/mapper/cryptswap1", before you can call "swapon".

To recap,
(1) cryptsetup luksFormat ... takes a physical partition /dev/sdX and creates a LUKS header on it. (It does NOT fill the partition with random data; you must do that yourself beforehand.)

(2) "cryptsetup luksOpen /dev/sdX name" unlocks the header and sets up a mapping from /dev/sdX to the name you choose, here cryptswap1. /dev/mapper/cryptswap1 depending on your udev version may be a symlink to a /dev/dm-X entry.

(3) mkswap /dev/mapper/cryptswap1 sets up swap space on the encrypted partition, the same as for a physical partition. Use the device mapper name and not the physical partition otherwise you will overwrite your LUKS header.

(4) swapon /dev/mapper/cryptswap1 should activate swap there.

You should also tell your /etc/fstab about this so that your system recognizes your new swap space after rebooting. Just change the swap entry from /dev/sdX or UUID=... to /dev/mapper/cryptswap1. You can also use the UUID shown by the mkswap command, but for starters try /dev/mapper/cryptswap1 to make sure it works. (Do not use /dev/dm-X - if you have multiple luks partitions the number of the entry dm-X may change across reboots.)
 
Old 06-28-2018, 09:39 PM   #3
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware14.2 64-Bit Desktop, Devuan 2.0 ASCII Toshiba Satellite Notebook
Posts: 2,568

Original Poster
Rep: Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704
Question

Quote:
Originally Posted by ordealbyfire83 View Post
Here I am assuming the last things you did are shown in the screenshot. I'm seeing a couple of things.

First, when you set up an encrypted partition by running "cryptsetup luksFormat ...", you are telling the cryptsetup program to prepare a LUKS header for a specific partition. This should be /dev/sdX and not /dev/dm-X. /dev/dm-X entries get created after "cryptsetup luksOpen ..." is run. Essentially you are double-LUKS'ing here.

Second, after you do get the partition properly "formatted", you need to manually set up swap space - this time on the 'dm' entry. You'll need to run, for example, "mkswap /dev/mapper/cryptswap1", before you can call "swapon".

To recap,
(1) cryptsetup luksFormat ... takes a physical partition /dev/sdX and creates a LUKS header on it. (It does NOT fill the partition with random data; you must do that yourself beforehand.)

(2) "cryptsetup luksOpen /dev/sdX name" unlocks the header and sets up a mapping from /dev/sdX to the name you choose, here cryptswap1. /dev/mapper/cryptswap1 depending on your udev version may be a symlink to a /dev/dm-X entry.

(3) mkswap /dev/mapper/cryptswap1 sets up swap space on the encrypted partition, the same as for a physical partition. Use the device mapper name and not the physical partition otherwise you will overwrite your LUKS header.

(4) swapon /dev/mapper/cryptswap1 should activate swap there.

You should also tell your /etc/fstab about this so that your system recognizes your new swap space after rebooting. Just change the swap entry from /dev/sdX or UUID=... to /dev/mapper/cryptswap1. You can also use the UUID shown by the mkswap command, but for starters try /dev/mapper/cryptswap1 to make sure it works. (Do not use /dev/dm-X - if you have multiple luks partitions the number of the entry dm-X may change across reboots.)
Here is the thing, I didn't do anything with the CLI when setting up the partitioning scheme. During install the Devuan installer of course uses a GUI; I guess that is both a good and a bad thing. The good thing is I am much too lazy & dumb (mainly the latter), to setup an encrypted partitioning scheme and LUKs. Only bad thing is that means on other distros that don't even use ncurses for setting up encrypted LUKs(Slackware), leaves me kinda screwed.

As for sdX, that is the problem for me because it sda5 is the extended partition which holds the encrypted LUKs. So AFAIK it gets complicated (maybe it really isn't and I am over thinking it), but since all I see is sda5, swap is on sda5 which well technically it is, but that cannot be right. It cannot be right in essence that I should just choose sda5 only, because won't that just screw up the entire LUKs partition? This is another reason why I am completely messing with this on a VM first.

So maybe there is another route, lsblk shows this:
Code:
devuser@devuan:~$ lsblk
NAME              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                 8:0    0   86G  0 disk  
├─sda1              8:1    0  116M  0 part  /boot
├─sda2              8:2    0    1K  0 part  
└─sda5              8:5    0 85.9G  0 part  
  └─sda5_crypt    254:0    0 85.9G  0 crypt 
    ├─volume-root 254:1    0   30G  0 lvm   /
    ├─volume-swap 254:2    0 15.3G  0 lvm   [SWAP]
    └─volume-home 254:3    0 40.6G  0 lvm   /home
sr0                11:0    1 1024M  0 rom   
devuser@devuan:~$
Or not, sda5 is crypt but all I know is per the last screen shot it is /dev/dm-2 ? This is where I am completely confused anyways, which though again if I fsck it up, I don't care because it is a VM. The only thing is this is the exact type of partitioning scheme I have setup on my notebook as I do on the VM.

Last edited by Jeebizz; 06-28-2018 at 09:41 PM.
 
Old 07-04-2018, 10:27 AM   #4
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 231

Rep: Reputation: 42
Ok, now we're getting somewhere. It wasn't clear from the screenshot that you're using LVM. Automated installers love LVM nowadays.

From the output of 'lsblk' sda5 is the root of the logical volume which itself contains a LUKS header. For this reason, sda5 is NOT visible to the operating system as a LUKS partition - the logical volume sda5 is.

Inside this encrypted logical volume you have three other logical volumes which, though encrypted, are probably unlocked using the key/password for the sda5-logical volume rather than individual LUKS partitions.

I guess all you really need to do is find the /dev entry for "volume-swap", set up swap space there, activate it, and add it to your /etc/fstab. The installer didn't do that, I guess, so that's likely a bug.

The device entry for that particular volume is probably set by udev and depending on the version and OS conventions that could vary, so you might have to poke around until you find it. In /dev, look for directories like /dev/volgroup or /dev/mapper.
 
Old 07-04-2018, 09:25 PM   #5
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware14.2 64-Bit Desktop, Devuan 2.0 ASCII Toshiba Satellite Notebook
Posts: 2,568

Original Poster
Rep: Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704
Quote:
Originally Posted by ordealbyfire83 View Post
Ok, now we're getting somewhere. It wasn't clear from the screenshot that you're using LVM. Automated installers love LVM nowadays.

From the output of 'lsblk' sda5 is the root of the logical volume which itself contains a LUKS header. For this reason, sda5 is NOT visible to the operating system as a LUKS partition - the logical volume sda5 is.

Inside this encrypted logical volume you have three other logical volumes which, though encrypted, are probably unlocked using the key/password for the sda5-logical volume rather than individual LUKS partitions.
Yep:

Click image for larger version

Name:	VirtualBox_Devuan_04_07_2018_21_21_50.png
Views:	9
Size:	4.4 KB
ID:	28046

Quote:
Originally Posted by ordealbyfire83 View Post
I guess all you really need to do is find the /dev entry for "volume-swap", set up swap space there, activate it, and add it to your /etc/fstab. The installer didn't do that, I guess, so that's likely a bug.
Perhaps, again I did not do any of this on a CLI, just used the Devuan installer


Quote:
Originally Posted by ordealbyfire83 View Post
The device entry for that particular volume is probably set by udev and depending on the version and OS conventions that could vary, so you might have to poke around until you find it. In /dev, look for directories like /dev/volgroup or /dev/mapper.
Well this is my fstab and crypttab:

fstab:
Code:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/volume-root /               jfs     errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=c8c98d6d-3804-4a4d-83d4-d0805dafb9aa /boot           jfs     defaults        0       2
/dev/mapper/volume-home /home           xfs     defaults        0       0
/dev/mapper/volume-swap none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/etc/crypttab
Code:
sda5_crypt UUID=dcc4a98c-e52b-4066-91ce-5075047388dc none luks

And I double checked - swap is on:

Code:
root@devuan:/home/devuser# swapon --summary
Filename				Type		Size	Used	Priority
/dev/dm-2                              	partition	15994876	0	-1
root@devuan:/home/devuser#

Last edited by Jeebizz; 07-04-2018 at 10:04 PM.
 
Old 07-08-2018, 06:06 PM   #6
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 231

Rep: Reputation: 42
So do you actually have swap available? Do you have nonzero output on the swap line from 'free -m'? In theory it looks like you should have this working.

Those error messages in your screenshot are to be expected. Basically what's happening is your kernel is reading arguments from your bootloader that don't exist yet. The grub 'kernel' (or 'linux' if in grub2) line probably has root=/dev/mapper/... and resume=/dev/mapper/.... Debian's initrd basically works like this

- Parse kernel command arguments and try to boot.
- No go, arguments show /dev/mapper stuff, so try lvm
- lvm stuff not active, is it encrypted?
- Check /etc/crypttab
- If Yes, unlock partition
- Try again

Their initrd has quite a lot of dark corners. The /etc/crypttab file is nothing standards-based and is only used by Debian-based initrd's. It would of course be better to make your own initrd that does exactly what you need, but that's an area that most people avoid. Unfortunately, as the kernel doesn't _natively_ support luks, an initrd is needed to create the necessary device notes and jump-start the system that way.

Just a heads up, if you have problems with hibernate/resume, LVM, not LUKS, is the likely culprit.
 
Old 07-09-2018, 10:17 AM   #7
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware14.2 64-Bit Desktop, Devuan 2.0 ASCII Toshiba Satellite Notebook
Posts: 2,568

Original Poster
Rep: Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704
Quote:
Originally Posted by ordealbyfire83 View Post
So do you actually have swap available? Do you have nonzero output on the swap line from 'free -m'? In theory it looks like you should have this working.
Correct, no swap is being used:
Code:
devuser@devuan:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:          16051         374       15336          16         340       15402
Swap:         15619           0       15619
devuser@devuan:~$
Quote:
Originally Posted by ordealbyfire83 View Post
Those error messages in your screenshot are to be expected. Basically what's happening is your kernel is reading arguments from your bootloader that don't exist yet. The grub 'kernel' (or 'linux' if in grub2) line probably has root=/dev/mapper/... and resume=/dev/mapper/.... Debian's initrd basically works like this

- Parse kernel command arguments and try to boot.
- No go, arguments show /dev/mapper stuff, so try lvm
- lvm stuff not active, is it encrypted?
- Check /etc/crypttab
- If Yes, unlock partition
- Try again

Their initrd has quite a lot of dark corners. The /etc/crypttab file is nothing standards-based and is only used by Debian-based initrd's. It would of course be better to make your own initrd that does exactly what you need, but that's an area that most people avoid. Unfortunately, as the kernel doesn't _natively_ support luks, an initrd is needed to create the necessary device notes and jump-start the system that way.

Just a heads up, if you have problems with hibernate/resume, LVM, not LUKS, is the likely culprit.
Perhaps again I am also making things more difficult. I am trying every which way to get a grasp on this entire concept with no success. Even before all this I have been reading README_LVM.TXT and README_CRYPT.TXT (within Slackware), I just do not get it (because yea I am dumb). Plus according to the Slackware way, you can't or shouldn't do an encrypted LVM/SWAP (cannot remember where I read it in those docs).

Either way now I feel really over my head in all this. I haven't given up yet, but yea I wish there was a more 'efficient' way, whatever that is.

Last edited by Jeebizz; 07-09-2018 at 10:19 AM.
 
Old 07-19-2018, 10:43 PM   #8
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 231

Rep: Reputation: 42
My apologies for the delay. I read through those files and indeed they are more complex than they need to be. Probably the best way to get more insight is to experiment with some pure LUKS containers (without LVM). There are any number of configuration options for creating a container, and most of that comes down to personal preference, level of paranoia, and the like. You can practice with creating containers that can be unlocked with a password or with a key file.

(As a warning, before deploying storage containers for production use, you should always make a backup container on a separate physical disk - if a hard drive fails, traditional data recovery methods likely will probably not work, even if you have the LUKS header.)

Most advocates for LVM claim that you can unlock multiple partitions with a single password for the sake of convenience (i.e. not having to unlock the root partition and swap separately). But one way around this is to make the swap unlockable with a key file and store that key on the root partition. That way, in your initrd you can write an instruction to unlock the swap automatically after the root partition is unlocked via your password.

The goal of the initrd would be to boot the kernel, mount a very minimal runtime environment, load the necessary kernel modules, unlock the partitions, mount the real root partition, and then switch_root to let the actual system boot up, or resume from swap. Initrd's such as Debian's are anything but simple and have a full-scale OS in there, which in my view, is a gaping security risk (i.e. do you really want networking and system administration utilies in there).

But alas, without writing your own initrd you are essentially stuck with using whatever method your distribution uses. But at least with some practice you could at least grasp what that initrd's procedure is and go with that.
 
Old 07-19-2018, 11:31 PM   #9
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware14.2 64-Bit Desktop, Devuan 2.0 ASCII Toshiba Satellite Notebook
Posts: 2,568

Original Poster
Rep: Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704
Quote:
Originally Posted by ordealbyfire83 View Post
My apologies for the delay. I read through those files and indeed they are more complex than they need to be. Probably the best way to get more insight is to experiment with some pure LUKS containers (without LVM). There are any number of configuration options for creating a container, and most of that comes down to personal preference, level of paranoia, and the like. You can practice with creating containers that can be unlocked with a password or with a key file.
No problem. As for this encryption thing I would find it a good idea to utilize it when possible. I.e. like a notebook something that you would have on hand away from home. I mean yea sure you can also encrypt your home computer's drive, but I dunno.


Quote:
Originally Posted by ordealbyfire83 View Post
(As a warning, before deploying storage containers for production use, you should always make a backup container on a separate physical disk - if a hard drive fails, traditional data recovery methods likely will probably not work, even if you have the LUKS header.)

Most advocates for LVM claim that you can unlock multiple partitions with a single password for the sake of convenience (i.e. not having to unlock the root partition and swap separately). But one way around this is to make the swap unlockable with a key file and store that key on the root partition. That way, in your initrd you can write an instruction to unlock the swap automatically after the root partition is unlocked via your password.
Hrmm, then maybe I should have multiple strategies, keep using both optical media and external HDs. Though I think encrypting external HDs might be more cumbersome and trouble than its worth. Also say if one has multiple HDs in a machine like I do, a primary SSD for the OS , and a conventional HD for /home, then I would have to probably enter the password twice still anyways? Yea encryption and LUKs are kinda involved.

Quote:
Originally Posted by ordealbyfire83 View Post
The goal of the initrd would be to boot the kernel, mount a very minimal runtime environment, load the necessary kernel modules, unlock the partitions, mount the real root partition, and then switch_root to let the actual system boot up, or resume from swap. Initrd's such as Debian's are anything but simple and have a full-scale OS in there, which in my view, is a gaping security risk (i.e. do you really want networking and system administration utilies in there).
This then would come down to the level security vs practicality then.

Quote:
Originally Posted by ordealbyfire83 View Post
But alas, without writing your own initrd you are essentially stuck with using whatever method your distribution uses. But at least with some practice you could at least grasp what that initrd's procedure is and go with that.
I guess again thats where I am held hostage. In terms of Slackware the documentation is itself involved, and yet not complete and it is all done by hand. I actually cannot even write a script to save my life. I kinda wish there was something middle of the road. I don't need a GUI , though some would argue that ncurses counts as one, I would be happy if Slackware at least had something like that in it's ncurses when setting things up initially, but it does not.

Sure Debian/Devuan you have the GUI and you don't have to worry about it, thats fine too. Even better if you are a lazy idiot . I am just lazy enough not to want to do something like this in a CLI, but thats just me.
 
Old 07-23-2018, 06:30 PM   #10
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 231

Rep: Reputation: 42
Quote:
As for this encryption thing I would find it a good idea to utilize it when possible. I.e. like a notebook something that you would have on hand away from home. I mean yea sure you can also encrypt your home computer's drive, but I dunno.
In addition to issues related to physical access, it's also a way of avoiding data remanence. With SSD's becoming more common, it's worth bearing in mind how they actually work. Unlike traditional drives which contain a small amount of extra sectors to use in case one goes bad, the true capacity of a SSD can be 50% greater than the advertised capacity. This "wear-leveling" tactic is what makes SSD's more reliable than flash drives. However, this extra capacity is inaccessible to the OS and cannot be erased this side of an external programmer, no matter how many times you run dd if=/dev/urandom of=/dev/sdX. The only way around this is to use brand new SSD's and only write encrypted data to them.

Further, using LUKS does slow things down a bit and this may cause some mismatch in data transfer rates to/from your SSD. The latest, blazing-speed drive isn't your friend here. This is somewhat of an edge case that the kernel developers seem not to give much attention to. If there is an issue you can try adjusting the kernel's dirty ratio and/or using something other than the cfq I/O scheduler. (Hint: you need to use the same scheduler for ALL connected storage devices (try setting it on the grub command line using elevator=deadline or similar) or else you'll get real trouble - think lockups requiring hard reset and fsck.)

Code:
echo 10 > /proc/sys/vm/dirty_ratio
echo 3 > /proc/sys/vm/dirty_background_ratio
But in any event even home computers should be secured, particularly for those living in rental properties or anywhere else where others have a key.

Encrypting external devices isn't much trouble. Depending on how your distribution compiled your desktop environment (if you're using one), Caja, Dolphin, and friends might prompt you with a password entry box. This should work for KDE 5, the newest versions of KDE 4, and Mate provided that cryptsetup was available at compile time.

Another thing to consider is whether your distribution uses or can use an /etc/rc.local file or similar. This is a file read by your init system and run at the end of the boot process. You can unlock multiple non-root drives here to avoid fiddling with an initrd. You'll need to set up a keyfile based unlocking scheme and place the key somewhere on your root partition (this is tolerable only if the root partition is encrypted). Then you could add a line similar to

Code:
cryptsetup luksOpen --key-file /etc/your-key-file /dev/sdXn mapper_name
If you decide to go the initrd route, remember you need to include every program you need and all of the shared objects down to libc. How much or how little you need is your call - I only have about 28 shared objects and about equally many programs. (As a test, you'll need to be able to chroot to its parent directory and be able to run the programs successfully with no access to your host OS.) At one time I started writing a tutorial for this but have yet to finish. It's one of those things that took a lot of hair-pulling to figure out but in retrospect looks ridiculously simple.

I guess the easiest would be to use the distribution's way of encrypting the root partition and getting this unlocked at boot time. Then use rc.local for unlocking all the non-root fixed drives, and handling external drives either on the command line or leaving that to your file manager.
 
Old 07-23-2018, 07:53 PM   #11
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware14.2 64-Bit Desktop, Devuan 2.0 ASCII Toshiba Satellite Notebook
Posts: 2,568

Original Poster
Rep: Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704Reputation: 704
Quote:
Originally Posted by ordealbyfire83 View Post
I guess the easiest would be to use the distribution's way of encrypting the root partition and getting this unlocked at boot time. Then use rc.local for unlocking all the non-root fixed drives, and handling external drives either on the command line or leaving that to your file manager.
I consider the Devuan setup fairly easy. Slackware is lacking in a point-and-click gui, which is fine by me. I just wish during setup it could be done through ncurses since that is used during the partitioning and selecting the software for installation in Slackware.

Last edited by Jeebizz; 07-24-2018 at 10:03 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Encrypted swap and hibernate Jeebizz Debian 2 06-12-2018 08:28 PM
Suspend / Hibernate with encrypted root and sapfile fl0 Slackware 1 11-29-2012 05:57 AM
How can I suspend & hibernate with encrypted lvm? yanfaun Linux - Laptop and Netbook 2 09-28-2010 01:49 AM
F7: Hibernate using new swap partition Mleahy Linux - Software 2 07-26-2008 02:16 PM
Some questions about swap and hibernate Ryzol Linux - Desktop 1 08-29-2007 07:34 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian

All times are GMT -5. The time now is 10:17 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration