How to extend my /home "LUKS" encryption to /var, /tmp and swap?

English Install/Boot/Login
#1

I’m trying out encryption for the first time and reading all the documentation I can find.
I am using a fairly generic partitioning scheme that includes a Windows 7 partition and an extended partition to house my swap, root and home partitions.

d830:~ # fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00098b6c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   314574847   157286400    7  HPFS/NTFS/exFAT
/dev/sda2   *   314574848   976773119   331099136    f  W95 Ext'd (LBA)
/dev/sda5       314576896   322971647     4197376   82  Linux swap / Solaris
/dev/sda6       322973696   406861823    41944064   83  Linux
/dev/sda7       406863872   976736255   284936192   83  Linux

Disk /dev/mapper/cr_home: 291.8 GB, 291772563456 bytes
255 heads, 63 sectors/track, 35472 cylinders, total 569868288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

I’ve read the following docs and portions:
[ul]
[li]SDB:Encrypted root file system - openSUSE[/li][LIST]

“Encrypting the root file system, as well as the home, tmp and other partitions is now fully supported in the Opensuse graphical installer. On already installed systems it can be done through the ‘Partitioner’ program in YAST.”

[li]Does that statement only refer to LVM managed file systems because I couldn’t encrypt the root partition - it gave an error? I’ve encrypted my /home to start with and not /var, /tmp or swap because I read this after I installed [/li][/ul]

[li]openSUSE 12.2: Chapter 10. Encrypting Partitions and Files - 10.2 Encrypted Home Directories[/li][ul]
[li]I don’t see the “file container” in my /home partition or the YaST partitioner… I was thinking this could be used as the key for /tmp, /var and swap. I don’t want to have multiple passwords/keys. Does /home even use a file container for it’s encryption? [/li]```
d830:~ # l /home
total 28
drwxr-xr-x 4 root root 4096 Sep 11 14:32 ./
drwxr-xr-x 24 root root 4096 Sep 14 11:25 …/
drwx------ 2 root root 16384 Sep 11 20:59 lost+found/
drwxr-xr-x 36 saultdon users 4096 Sep 14 11:45 saultdon/

 
[/ul]
  
[li][openSUSE 12.2: Chapter 10. Encrypting Partitions and Files - 10.1.2 Creating an Encrypted Partition on a Running System](http://doc.opensuse.org/documentation/html/openSUSE/opensuse-security/cha.security.cryptofs.html#sec.security.cryptofs.y2.part_run)[/li][ul]
[li]There isn't anything here to actually tell me how to do this. I understand that I can enable encryption on the partitions /tmp, /var and swap but that this will re-format them. Can I do that while the system is actually "running" or do I have to boot from a live disk to format them? I thought I didn't have to re-format the swap? But will this also require me to have three passwords at login even if I apply the same password to all of them that matched the encrypted home? [/li][/ul]
  
[li][Using Luks encrypted partitions in linux](http://nwrickert2.wordpress.com/2012/05/03/using-luks-encrypted-partitions-in-linux/)seems like a good article and is trying to accomplish something similar to what I want to do.[/li][ul]
[li]Is it safe to manually add the required entries into /etc/crypttab, comment out the /etc/fstab entries and reboot, or do I really have to decrypt them then format like it's suggested? [/li][li]Can I just add an entry for "/" in /etc/crypttab to finally encrypt root as it's not allowed during installation phase? [/li][/ul]
      
[/LIST]

Basically, at this point, [b]I have /home encrypted and want to share that encryption key with the other partitions like swap, /var and /tmp[/b] as suggested in the docs. Encrypting /root would be a plus, but for now if I can learn how to at least extend it to the others, that would be a start. I would like to just use YaST partitioner and enable encryption on /var, /tmp and also swap with matching passwords. But I'm thinking that this will have me entering 4 passwords at boot, even though they all match for /home, /var, /tmp and swap.

I am totally new to encryption and still wrapping my head around the concepts and how it runs on the openSUSE platform. Any other information I can provide or help me clarify my understanding is greatly appreciated.

Here is a picture of my current setup under YaST partitioner and nothing is under 'crypt files':[IMG]https://lh5.googleusercontent.com/-TNaNoVi7b5M/UFI2YmAgdUI/AAAAAAAAAiI/ZJIzD7-M8Nw/s800/YaST-Partitioner-Setup.png[/IMG]
#2

Your best bet will be to use an encrypted LVM. You will need a separate “/boot” partition for that. See
Using an encrypted LVM for linux

With that setup, “/boot” (make it say 200M in size) will be unencrypted. Your root, home and swap as part of the encrypted LVM will be encrypted.

#3

On 2012-09-13 21:46, saultdon wrote:
>
> I’m trying out encryption for the first time and reading all the
> documentation I can find.
> I am using a fairly generic partitioning scheme that includes a Windows
> 7 partition and an extended partition to house my swap, root and home
> partitions.

The system that yast uses is create one large encrypted LVM “partition” or enclosure, which
inside contains all the partitions you need, like root, var, tmp, home… You only enter the
passphrase once, for the LVM. There has to be also a separate /boot, non-encrypted.

I’m not aware that you can create this setup once the system is installed.

There are also procedures to encrypt the system without LVM, but it can not be done by Yast.
There are some posts in the security mail list that explain how to do it. However, I do not
know how systemd would cope with that.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#4

I’m going to try the LVM scheme, but I’m curious how much system resources (encrypt/decrypt on the fly) will be used and how that will affect performance and boot time.
I use linux for GIS visualization and geo-processing, so that can require several r/w operations and those can be small files or large ones depending on my data source.

A question about the partitioning in response to @Robin’s comment:

Do I put the /boot partition outside of the extended partition and then set it to boot from /boot and not the extended partition?
Because when I make an extended partition to hold the rest of the linux partitions, openSUSE will try to boot from the extended so that I don’t need to make a /boot partition and the hard disk MBR remains untouched.

I see my final partitioning looking like:

   Device Boot System 
/dev/sda1      Windows7
/dev/sda2   *  /boot 
/dev/sda3      extended 
/dev/sda5      swap 
/dev/sda6      / 
/dev/sda7      /home

Or do I put the /boot inside the extended partition and tell it to boot from /boot?
I was thinking of getting rid of the extended partition all together but I read that I could run out of primary partition spaces (limit is 4) so I need the extended for the extra partitions.

#5

Why use an encrypted LVM? There are two things that I liked about the encrypted LVM system.

  1. Everything is encrypted. Well, almost everything. A separate small unencrypted “/boot” partition is needed. The kernel is loaded from there, and the crypto setup is done there. With almost everything encrypted, there is no concern about leakage of sensitive information. Everything I do that goes to disk will go to encrypted space. The only exception is the system kernel an few modules and configuration used in startup. What I do in my normal usage of the system is unlikely to ever end up in the “/boot” partition, so it is not a worry that “/boot” is unencrypted.
  2. Almost all of the linux install is within a single partition (the partition assigned to the LVM). This still allows me to have separate file systems for “/” and “/home” and separate swap. But those all live within the same LVM, resulting in a simpler disk organization.

Those two points sounds like I am going to learn a bit about LVM partitioning and I could be over thinking this with the whole /boot vs extended thingy.
It also tells me that yes, I do boot from /boot and it is ‘outside’ of the other partitions that are ‘inside’ the LVM.

Oh, I love linux.

#6

I am not noticing significant resource for encryption. I do have a computer with 12.2 installed in an encrpted LVM, and with 12.2 RC2 on a separate partition with only swap encrypted. If you can think of a timing test, I could try that.

I would think that most of the cost of encryption will already be there with your encrypted “/home”. And that’s because of the buffering that linux uses, so that most files on the root partition will not be read very often since a copy will be retained in memory as long as there is sufficient RAM.

You can do that either way. Since you will probably have to backup “/home”, repartition and reinstall, then I would suggest that you make “/boot” a small primary partition, and boot from there.

If you put “/boot” in the extended partition, then it will still try to boot from the extended partition. That’s because it needs a primary partition for booting. If you make “/boot” primary, then the install default will be to boot from “/boot”, or at least that has been my experience. Either way, the MBR remains untouched.

#7

That’s not true. The fact that you don’t install Grub to MBR doesn’t mean that the MBR remains untouched. By default openSUSE setup writes it’s own generic boot code, which is totally different from Windows generic boot code (if you compare the two). It also does that when you reinstall the boot loader with YaST. Of course, they do exactly the same thing. But in case it is desired to keep Windows generic boot code, you have to explicitely uncheck “write generic boot code to MBR” in the boot loader options. And if you already have Grub or another boot manager in MBR, you might want to uncheck this option too.

fingrub shows which kind of generic boot code is installed. See this post which displays both, Windows and SUSE generic MBRs: http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-17.html#post2443638.

#8

I forgot about that this time around and it was left checked even though I am booting from the extended partition.
I thought I learned my lesson about playing with the Windows MBR because I was at one point re-installing grub (legacy) every time Win7 decided to update, not just service packs but also Malicious Software Removal patches.
I just don’t use that OS often so haven’t seen it in a while :X
My *nix transition has been fairly smooth.

Nice script, thanks for sharing.

#9

In my case, I really like the LUKS encryption because I can append that initrd option to the end of the mount points found in /etc/crypttab.

This is important because I need to have remote access to my home PC (desktop) and can issue a magic packet from WOL via my router to wake the beast from a suspended (to ram) state.

I don’t know if I can wake from a suspended state and not be bothered with a decryption password to resume the desktop if I decide to use LVM.

I’m trying to avoid getting stuck in a scenario where I have to keep my desktop turned on and logged in because of LVM encryption, thought LVM is looking a lot easier to setup.

Before I try an LVM scheme, I would like to see if I can use LUKS to encrypt at least /home, /var, /tmp and swap under a single encryption key so I only need to use one password entry to decrypt the whole lot.
I don’t mind re-installing from scratch as I have good backups to restore my home and whatnot but I can’t find any good documentation on how to setup LUKS like this or even what to put for the pathname or size…

Going to keep reading whatever I can scrounge up as there isn’t anything specific in the openSUSE security doc because that only tells me that it’s possible but not how.

#10

Every time that I have looked at that setting during install, it has been unset already. I never had to do anything.

#11

Don’t do that with 12.2. In my experience, it causes problems due to the way that plymouth splash handles the encryption key.

If you are using an encrypted LVM, the that will be handled in the “initrd” anyway. That’s why a separate “/boot” is needed.

#12

Luckily for me, I’ve removed all plymouth packages and splash* related packages. That sounds like another headache I don’t want to deal with.

I’ve been running a luks setup on my laptop to test it out earlier today and it’s booting fine. I’m betting it’s because of the disabled splash/plymouth stuff.
I use splash=0

Does LVM require a password when resuming from sleep (suspend to ram)?

#13

I have considered that. I really don’t need plymouth. In previous versions, I always modified the boot settings to not use splash. I like to see those messages during boot.

Great.

No, it doesn’t.

#14

Every time I’ve looked (and I look every time) it has always been set. Today - Thu Sep 13 21:05:00 PDT 2012 - in the setup I’m running right now, it is set…

http://imageshack.us/a/img829/965/opensuse122setup.jpg

I would be really thankful if you would explain to me what I’ve been missing for so many years in openSUSE setup … although I don’t mind unchecking this option (as I do almost every day).

I’m not kidding. Prove me that I am wrong and I will apologize for all the criticism I’ve formulated against openSUSE setup (especially this “destructive” option) in the past years… And what about all Ubuntu dual booters desperatly looking for their Grub after installing openSUSE? (those who were clever enough to ask before and follow my advice did fine). Well, over time, quite many people had the curiosity to look at this settings, uncheck this option and thank me afterwards for preserving their MBR. But nothing is 100% sure. Maybe I’ve just been hallucinating all the time.

More seriously, if this option is indeed unchecked in some cases, we would like to know in which case exactly. So how about booting with the install DVD, running the setup, telling us exactly what you select in Boot Loader Installation, clicking on Boot Loader Options … and reporting what you see there? It shouldn’t take longer than 5 minutes. Then, just cancel the installation and you’ll be back in business.

Also, if you’re dual booting with WIndows (I think you do on some machines) how about posting findgrub’s output? I bet you’re using SUSE generic boot code and not WIndows. If so, how come?

I found an old findgrub output you posted once (http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/463258-secondary-grub-boot.html#post2367653) but it was version 3.4. Generic MBR detection has been implemented since version 3.7.2 (http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-16.html#post2443550). Latest version is 4.1 (which doesn’t fully support Grub2 2.0 - but it’s pretty new.)

#15

On 2012-09-14 03:56, saultdon wrote:

> the beast from a suspended (-to ram-) state.
>
> I don’t know if I can wake from a suspended state and not be bothered
> with a decryption password to resume the desktop if I decide to use LVM.
>
> I’m trying to avoid getting stuck in a scenario where I have to keep my
> desktop turned on and logged in because of LVM encryption, thought LVM
> is looking a lot easier to setup.

It doesn’t matter how you encrypt the disk and if you suspend to ram, it is irrelevant. It may
be an issue if you hibernate (to disk).

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#16

Obviously, I don’t know what is happening on your system.

Recently, I installed on a system with a disk that had been completely wiped. I intended to check and make sure that the flag was set, but I forgot. Fortunately, the system worked after install.

My best guess is that the installer is checking, and does not install generic boot code if its check shows that there is already generic boot code. Since I leave my systems with generic boot code, it does not default that flag on. I think you usually install grub in the MBR so it would not detect the presence of generic boot code and defauts it to on. To repeat, I am guessing here, based on what I have been seeing.

#17

Next time stop guessing, just check! openSUSE writes ist generic boot code into MBR, no matter what’s in there: nothing, Grub, another boot loader, Windows generic boot code or another openSUSE generic boot code. It doesn’t check (and doesn’t care).

#18

Wrong! Wrong! Wrong!

That, I have been checking. And you are wrong.

#19

You’re right (and thus I’m wrong). And you were well inspired in repeating it 3 times. I tried on WIndows 7 and XP virtual machines with openSUSE 12.2 and 12.1 Live CD as well as 11.4 install DVD … and according to what I saw, the setup didn’t intend to overwrite the MBR to my big surprise (option was unchecked). On the systems I usually set up, whith several Linux distros and 3 or more BSDs, it would show no mercy (that, I can tell you). How happy you guys must be to dual boot with Windows! Anyway, I don’t know if it would have written its generic boot code after all (that could not be totally excluded) because it failed to resize the partitions and I decided to not to waste my time an hurt my brain any longer with Windows virtual machines.

#20

I doubt that it make much difference on whether there is the Windows boot code or the opensuse generic boot code, so not much effect on happiness.

The reason that I have my dual boot systems default to booting Windows, is because they can boot Windows unattended, whereas I have to be there to enter an encryption key for opensuse (using encrypted LVM).

I recently switched my main desktop to a linux-only system, so I no longer have to reboot it twice a week to update Windows AV.