Looking for some advice on encrypting root, home file systems

English Install/Boot/Login
#1

Hi,

I’ve recently put openSUSE 11.4 on a laptop, and I would like to encrypt the root and home partitions, but did not do that during installation. I’ve read the official openSUSE documentation on encrypting root file systems SDB:Encrypted root file system - openSUSE.

It appears that in YaST, I can assign encryption to nearly any of my partitions post-installation, although I doubt it will work on /boot or my swap partition (am I wrong?). Here is my partition table:

linux:/home/andy # df -hl
Filesystem Size Used Avail Use% Mounted on
rootfs 40G 5.0G 33G 14% /
devtmpfs 2.0G 296K 2.0G 1% /dev
tmpfs 2.0G 2.8M 2.0G 1% /dev/shm
/dev/sdb3 40G 5.0G 33G 14% /
/dev/sdb1 98M 37M 57M 40% /boot
/dev/sdb4 647G 139G 475G 23% /home

I’m wondering if anyone has experience with encrypting partitions post-installation, and is it a good idea to try it, or would I be better off doing a fresh install with encryption? Also, if anyone has recent experience, how much of a speed loss am I likely to notice on a laptop if I encrypt the root and home partitions? I recall that when I used an encrypted /home partition on a laptop with LVM in the SuSE 9.3 days, there was a significant slowdown.

Any thoughts would be greatly appreciated.

#2

Please use CODE tags around your computer output (and not Quote tags) like the partition table above. It prevails he layout you see in the terminal and thus makes it readable to others: Posting in Code Tags - A Guide

And I may add that

df -h

does not display a partition table. The man page says: “df - report file system disk space usage”.

sudo /sbin/fdisk -l

does

#3

OK, thanks Henk.

Here is the partition table for the drive using sudo /sbin/fdisk -l:

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00032a76

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048      208895      103424   83  Linux
/dev/sdb2          208896     4401151     2096128   82  Linux swap / Solaris
/dev/sdb3         4401152    88293375    41946112   83  Linux
/dev/sdb4        88293376  1465147391   688427008   83  Linux

The first partition is /boot, then swap, then root, then /home. /dev/sda contains an old Windows Vista installation that is sitting unused at this time.

Andy

#4

On 2011-05-12 19:06, andyprough wrote:

> It appears that in YaST, I can assign encryption to nearly any of my
> partitions post-installation,

No, that is not possible. The process of encrypting a partition includes
destroying all the data it contains.

I suggest you search this forum for the subject “encrypt”, there are many
posts with lots of interesting info.

> I recall that when I used an
> encrypted /home partition on a laptop with LVM in the SuSE 9.3 days,
> there was a significant slowdown.

There is a slowdown, most certainly. It depends on how powerful your cpu
is, but it will never write as fast as without encryption.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

#5

Hi Carlos,

Oh, I see. I had read on the SDB page that “On already installed systems it can be done through the ‘Partitioner’ program in YAST”, and I thought this meant that YaST was capable of retaining the information on the partition. However, I found the Novell Security guide for SuSE (Novell Documentation), and I see that you are right - “encrypting an existing partition destroys all data on it and requires resizing and restructuring of existing partitions”.

This means I would need to do a reinstall. Not a problem. Unless I create an encrypted container file:

Instead of using a partition, it is possible to create an encrypted file of a certain size that can hold other files or folders containing confidential data. Such container files are created from the YaST Expert Partitioner dialog. Select Crypt Files > Add Crypt File and enter the full path to the file and its size. If YaST should create the container file, activate the checkbox Create Loop File. Accept or change the proposed formatting settings and the file system type. Specify the mount point and make sure that Encrypt Device is checked.

I assume that the root partition could not be run in a container file? Sounds like a messy way of doing things - I’ll probably opt for the reinstall.

Thanks,
Andy

#6

This may be of interest, https://launchpad.net/ecryptfs

It is also what Ubuntu uses when you tick the encrypt option during the installer.

#7

On 2011-05-12 21:06, andyprough wrote:
>
> Hi Carlos,
>
> Oh, I see. I had read on the SDB page that “On already installed
> systems it can be done through the ‘Partitioner’ program in YAST”, and I
> thought this meant that YaST was capable of retaining the information on
> the partition.

It can create new encrypted filesystems, yes.

> This means I would need to do a reinstall. Not a problem. Unless I
> create an encrypted container file:

Mmm?

>
>> Instead of using a partition, it is possible to create an encrypted file
>> of a certain size that can hold other files or folders containing
>> confidential data.

Ah, yes. I use that now and then.

>
> I assume that the root partition could not be run in a container file?
> Sounds like a messy way of doing things - I’ll probably opt for the
> reinstall.

Quite messy :slight_smile:

I do not have an encrypted root, so I can not really guide you there. I use
encrypted data partition for confidential data storage. But the procedures
have been discussed here several times.

The YaST method consists, as far as I know, on creating an encrypted LVM
container which holds everything: swap, root, home (not boot, I think). You
enter the password once, for the LVM. However, I do not like LVM, it is
another layer of complication.

However, one of the posts here described an alternate method (requirement
is entering the password just once) with several partitions. I have
forgotten the details, because I have forgotten to write a note describing
the procedure for myself. But it is in the post if you search for it. A
month or two ago, I think.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

#8

I went through those kinds of decisions recently.

My final decision:

Encrypt “/home” and swap. Mount “/tmp” from swap (i.e. tmpfs), so that anything from “/tmp” that is stored on disk is stored encrypted.

I checked “/var/tmp”, but I didn’t see anything being saved there that concerned me.

I decided not to encrypt the root partition, because that would make it hard to do boot from a rescue disk and repair problems.

I am not noticing any slowdown with the encrypted swap and “/home”. In other words, if there is any slowdown, it is too small to notice (even on an older slower machine).

If I had wanted to encrypt the root partition, then by far the easiest method would have been to use LVM (logical volume management). Doing it that way, you need a separate unencrypted “/boot”. But apparently it is then easy enough to tell the installer to encrypt the entire logical volume. I have not actually tried doing that.

#9

Hi nrickert –

Thanks - that is a great solution! I found a method for mounting /tmp from swap on a Fedora discussion list as follows:

You can mount /tmp as tmpfs and it will use RAM and swap. Since you just encrypted swap, there is no need to re-encrypt /tmp.

Just put the following in fstab:

'tmpfs  /dev/shm  tmpfs  size=512M,noexec,nosuid  0 0'

That will cap /tmp usage to 512M. It grows/shrinks dynamically.

Is this what you are referring to?

#10

On 2011-05-13 00:06, nrickert wrote:
> I am not noticing any slowdown with the encrypted swap and “/home”. In
> other words, if there is any slowdown, it is too small to notice (even
> on an older slower machine).

You have to compare the operations in the same machine with and without
encryption. I just wrote a 1 GB file on two partitions of the same HD, one
encrypted, the other not. That HD is otherwise idle at the moment.

> time dd if=/dev/zero of=test bs=100M count=10
10+0 records in
10+0 records out
1048576000 bytes (1,0 GB) copied, 2,96997 s, 353 MB/s

real 0m2.994s
user 0m0.000s
sys 0m1.578s

> time dd if=/dev/zero of=test bs=100M count=10
10+0 records in
10+0 records out
1048576000 bytes (1,0 GB) copied, 1,79477 s, 584 MB/s

real 0m1.816s
user 0m0.001s
sys 0m1.384s

The first one is encrypted; you can see the difference. And mine is a fast
machine.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)

#11

I am just using:


none    /tmp    tmpfs   defaults        1 2

Yes, I could have added the “size=” parameter, but decided that I didn’t need that when I am the only user.

And a note on encrypting swap. When going through the install, ask for the swap partition to be encrypted and formatted. When prompted for a password, leave the password field empty. That way, swap will be encrypted with a random password and a new “mkswap” run on it for every boot. On my first attempt to do this, I made the mistake of supplying a password, which I then had to enter during boot.

For “/home”, on the other hand, you will need to provide a password. You won’t want that reformatted every boot.

#12

Hi nrickert –

That worked out perfectly – much better to do it without a password. With a password, even when I entered the password correctly at boot, swap was not loading. Your fstab line worked great as well. I guess the advantage of a no-password encrypted swap file and /tmp directory is that they do not retain any information between boots?

This way, I probably will not have to reinstall. I will resize my /home partition, and make a second, encrypted partition off of /home that contains all my confidential documents. I should be able to set the mountpoint at the time of installation from the YaST Partition Manager.
Thanks!
Andy

#13

Great. I’m glad you have it working.

Yes, the swap and “/tmp” won’t have any accessible information between boots. What information they have will be encrypted with an unknown random key.

There is one downside. Recovery from hibernation probably won’t work, since hibernation normally functions by dumping system memory to swap. That was okay for me - I don’t like hibernation, anyway.