Full Disk Encryption - Multiple partitions
- Inicie sesión o regístrese para enviar comentarios
Hello!
I'm trying to implement this https://trisquel.info/en/wiki/full-disk-encryption-install, but i wanted to do it to a system with multiple partitions and to have them all encrypted (from what i was able to understand that documentation applies only to the swap area and root partition, but it doesn't contemplate having /tmp, /var and other separate partitions and to encrypt them also).
I have partitioned my hard drive in the following way:
- /dev/sda1: /boot (200 MB, EXT2, Primary)
- /dev/sda2: /swap (2 GB, swap, Primary)
- /dev/sda3: (Extended)
- /dev/sda5: /tmp (18 GB, XFS, Logical)
- /dev/sda6: /var (16 GB, XFS, Logical)
- /dev/sda7: /root (16 GB, XFS, Logical)
- /dev/sda8: /usr/local (6 GB, XFS, Logical)
- /dev/sda9: /usr (32 GB, XFS, Logical)
- /dev/sda10: /opt (8 GB, XFS, Logical)
- /dev/sda11: /home (200 GB, XFS, Logical)
Note: I have chosen this partitioning scheme and file system based on what i read on-line, with performance and stability in mind. I even chose the partitioning order trying to reduce the amount of disk searches (...maybe a bit silly of me)! If you have anything to point out to the way i have partitioned my hard drive, any tip or recommendation, please do so!
Actually, i've just formatted /dev/sda1 with ext2 and will leave it unused for now, because i intend to put the boot partition, with GRUB and the kernel, in an external USB thumb drive, for added security.
Basically, my question is: will i have to encrypt every single partition, one at a time, with cryptsetup -y --cipher aes-xts-essiv:sha256 --key-size 512 luksFormat /dev/PARTITION and, from there, work with each one individually, as explained in the link i've placed at the beginning of this post, or is it possible/recommended to encrypt the whole extended partition area (/dev/sda3) in place?
Any comment would be much appreciated. Thank you!
I am a member!
My best bet would be on a fresh install with the NetInstall and the option of encrypted LVM; this would make 3 partitions something like this:
/dev/sda1 = /boot
/dev/sda2 = extended
/dev/sda5 = logical encrypted with cryptsetup and partitioned with LVM
And sda5 has swap and root under the encryption. I suppose u can resize the lvm partitions and managed them the way you want and afterwards updating the /etc/fstab file.
If you can, I strongly recommend you to play in a virtual environment (ex. VirtualBox) before trying on the real box.
Also, keep in mind that if you manage to successfully encrypt all the partitions you want, in the current configuration, you'll have to enter the password for each of them at boot.
If you have anything to point out to the way i have partitioned my hard drive, any tip or recommendation, please do so!
You basically have a swap partition, an ext2 file system mounted on /boot (what makes sense; I made the same choice) and then multiple partitions where XFS file systems are mounted. I do not understand how this multiplicity presents advantages over one single XFS file system mounted on / (I would, of course, understand if different file systems were chosen). That may just be my ignorance speaking but I only see a major drawback: because it is hard to predict the required sizes, you will end up with full partitions, whereas other ones will be almost empty. Using LVM, as teodorescup suggests, would certainly help in resizing the partitions (notice that XFS partitions cannot be shrunk!) but why attempting to fix a potential problem if you could simply avoid it?
Assuming there is an advantage in multiplying the partitions (please, explain me), the allowed spaces look wrong if the system is used as a desktop. If it is so, take a look at the occupation, on my laptop, of the various repertories you list (and comments I have added after the '#' characters):
$ sudo du -hxs /boot /tmp /var /root /usr/local /usr /opt /home
29M /boot # One kernel only (you want 3-4 times more to easily revert to an older kernel in case of problems with a brand new one).
72K /tmp # This might grow up to a few GB... but 18?! I would like to know what kind of applications would need that much.
524M /var # Cleaning some DEB packages with 'apt-get autoclean'.
500K /root # I must have 'su' to root a few times but Trisquel's user are invited to use 'sudo' and /root therefore remains empty.
252K /usr/local # Very far from the 6 GB but you may intend to place there your own developments, do you?
4,6G /usr # You will much need more if you install applications that require much space (such as games that come with fancy graphics, musics, etc.) but, anyway, 32 GB looks a lot.
271M /opt # I have placed there a free applications I downloaded from the Web (it is not in Trisquel's repository); my /opt would be totally empty otherwise.
147G /home # /home grows and grows and grows ... It must definitely use the whole remaining space once the sizes of the other partitions were defined.
To sum up the size choices that look weird to me (but again, you may have special workloads in mind): /tmp, /root, /usr/local and /opt appear a lot too large; /var and /usr look too large (like in "they could be divided by 2"). The freed space would go to /home.
The choice of the XFS file system for partitions typically having small files (like /tmp and /var, which typically have kB-large files) also looks weird to me. I have always read XFS is extremely efficient with large files but not with small ones. Is this reputation ungrounded?
Well, first of all thanks for all the comments so far.
I've chosen to have all these multiple partitions because I've read somewhere (can't remember exactly where... maybe somewhere in tldp.org or searching some partitioning-specific tip with some search engine) that it is a good idea to do so, especially with /var and /tmp since some bad behaviored app might keep swelling log or temporary files untill it fills up the entire hard drive.
Also, I've read that, sometimes, it is a good idea to make some partitions read-only, like /usr or /usr/local since their content won't be changing (unless updating - installing more apps, uninstalling...) and this may help preventing some malicious intruder from corrupting some system app and implementing some kind of exploit.
About the chosen sizes for each partition... you're absolutely right: it is difficult to predict the required sizes and, of course, even if we do get it more or less right, our own requirements may vary across time - that's why I've exaggerated in setting them with so much available space. And yes, i was intending to use /usr/local for my own developments, in the future.
About using XFS with small files, you're right and i do remember reading exactly that: XFS is more efficient with large files and less with small ones... don't know how I've missed that! Anyway, I'll have to go back and read those wikipedia descriptions of the various file systems so that i can choose one that seems right. I've read something that JFS might be a little less CPU/power consuming when performing operations on files... that also appeals to me - will have to read it again and find my balance.
Then again, i know i might be overdoing it and complicating something that shouldn't be all that much complicated... I'm just installing Trisquel 5 on my 64 bit laptop from scratch, with my hard drive completely clean, and i want to make all the pieces have the best fit all together from the very beginning. You can call me a detail freak, or simply a silly masochist. :)
Thank you for the explanations.
I now understand your idea of mounting /var and /tmp on separate partitions... although I believe you will more probably end up filling up the whole /home with legitimate data than filling up these two partitions with crap. Once this happens you would want to shrink the space granted to the /var and /tmp partitions... but that is not possible with XFS! Notice also that, the content in /tmp and most of the content in /var (such as the logs you mention) can be safely removed if necessary. /tmp/* is actually automatically cleared at each shutdown (or startup?).
Mounting /usr in read-only must be a pain: every time you want to update the system (and that typically happens once or twice a week), you would need to remount the file system without this option. Since these updates mainly deal with security fixes, don't you fear to postpone the update (for convenience) what could actually be a greater security threat?
Finally, you do not mention /root and /opt. As far as I understand, these directories are, with a "normal use" of Trisquel, always empty. That is why I do not understand the point of having them on separate (empty) partitions.
Hello!
Great efforts, I do it too.
I have some tips:
1. You could use GPT instead of MBR; an advantage is that you don't need extended partitions, another is the CRC32 integrity-check mechanism; see:
· https://duckduckgo.com/GUID_Partition_Table
· https://wiki.archlinux.org/index.php/GUID_Partition_Table
Trisquel has gdisk and GRUB 2 in its repos.
2. You could use a separate /srv partition too. For more on partitioning schemes, I recommend this:
· https://duckduckgo.com/Filesystem_Hierarchy_Standard
· https://wiki.archlinux.org/index.php/Partitioning
3. For security:
· https://wiki.archlinux.org/index.php/Security
Because I had no time to setup it the best way, I do not encrypt my workstation partitions -- only those in my notebook (all-in-one LVM encrypted). Here is a sample of my workstation's good-to-Trisquel (I have to uninstall old kernel packages, freeing /lib, before upgrading linux-libre in order to have space in /... ;P I migrated from Parabola to Trisquel and didn't foresee this!) /etc/fstab (I separated everythig possible from /):
# file system mount point type options dump pass tmpfs /tmp tmpfs nodev,nosuid 0 0 #906 GiB LABEL=home /home ext4 defaults,relatime,nodev,nosuid 0 2 #60 MiB LABEL=t_boot /boot ext2 defaults,relatime,nodev,noexec,nosuid 0 2 #378 MiB (make it bigger; let's say 512 MiB for safety...) LABEL=trisquel / ext4 errors=remount-ro,relatime 0 1 #6,9 GiB LABEL=t_usr /usr ext4 defaults,relatime,nodev 0 2 #1,0 GiB LABEL=t_var /var reiserfs defaults,nodev,nosuid 0 2 #504 MiB LABEL=t_opt /opt ext4 defaults,relatime,nodev,nosuid 0 2 #504 MiB LABEL=srv /srv ext4 defaults,relatime,nodev,noexec,nosuid 0 2 #2,0 GiB (same space as in my RAM memory) LABEL=swap none swap sw 0 0
My bests!
Just wanted to say that i've seen this: https://wiki.archlinux.org/index.php/Security#Potential_usage and have made my /var partition mount with the noexec option, like it was suggested there, and everything fell apart when updating Trisquel. I was getting "no permission" messages when installing the packages.
May work in Arch but not in Trisquel.
Indeed. "noexec" in /tmp causes something similar.
I tried these three security mount options (nodev,noexec,nosuid) in each mount-point; a Trisquel with this /etc/fstab should totally works.
I am a member!
What about putting /tmp in memory? Is there any reason to even store that on the disk? I'm assuming you have a sufficent amount of memory.
Hi Chris,
there is a reason to store /tmp on the disk: space needed within it. Some tasks use much of it, like building OpenOffice (I tried it in 2010 in ArchLinux and it stopped when filled up my 8GB /tmp partition) or editing big audio/doing many tasks into a single Audacity session (Audacity comes configured by default to use /tmp for temporary files; it's possible to change that). There is no swap for tmpfs. On doing such tasks, this sufficient amount of memory can be huge...
However, /tmp is much faster on RAM than on disk. I think it's better to close Audacity and open it again when needed than to wait for minutes to have an audio safety copy. And I never tried to build OpenOffice/LibreOffice again, nor do I build anymore every package in my system.
Also, as tmpfs, it's for sure that /tmp will be cleaned on system halt; I don't know if the default is to clean it on boot, but I prefer in halt. Probably this cleaning-up on halt enhances privacy compared to it on boot.
Aaaand putting it in RAM, where it's size is limited and dynamically managed, saves disk space for other things.
tmps does support swapping once it reaches its size limit (half of the RAM by default but the size option changes that): https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt
In the description:
tmpfs puts everything into the kernel internal caches and grows and
shrinks to accommodate the files it contains and is able to swap
unneeded pages out to swap space.
Interestingly, it is written later:
Some people (including me) find it very convenient to mount it e.g. on /tmp and /var/tmp and have a big swap partition.
Great! Thanks, I didn't know this. Sorry for my mistake!
Just assumed there was no swap because Audacity comes to errors when fulfilled RAM. So, it must be for speed differences between RAM and disk. Or, maybe, Audacity can't handle it... don't know, have to sleep. Bye! Hasta la vista.
Once again, thanks to all! Everyone's comments were helpful.
I'm gonna chew on all that info, but right now i have doubts about putting /tmp in memory, like Chris recommended and sphynx also uses, from what i've seen in his fstab file:
- Isn't there a danger in placing /tmp in memory (just like an app could fill up all that partition's available space it could also use up all the system's available RAM and, eventually, swap space, taking the system down to it's knees, which would be much worse than simply filling the whole /tmp partition)?
- If i do choose to place /tmp in memory, how do i do it? Don't create any partition for /tmp and just edit
/etc/fstabafter installing the system?
By the way, my laptop has 4 GB of RAM, so i guess there would be no problem in placing /tmp in memory, from an availability of resources point of view, right?
apvp,
1. "By default, a tmpfs partition has its maximum size set to half your total RAM, but this can be customized. Note that the actual memory/swap consumption depends on how much you fill it up, as tmpfs partitions do not consume any memory until it is actually needed." See: https://wiki.archlinux.org/index.php/Fstab#tmpfs
I have 2 GB of RAM:
$ df -h
[...]
[FS Size Used Disp. % Mount-poit]
tmpfs 940M 52K 940M 1% /tmp
[...]
$ free -m
total used free shared buffers cached
Mem: 1879 1479 399 0 12 608
-/+ b/c: 859 1020
Most of this RAM consume is for Firefox and audio things.
2. Almost exactly -- do it before starting up the system for the first time.
Using /tmp as tmpfs also speeds up /tmp read and writing speed. In my experience, it accelerates boot; probably does it to package managing too, since in Trisquel it uses /tmp (found it out by experimenting various /etc/fstab configs; Synaptic gave me some messages. My /etc/fstab options are fully ready for Trisquel -- the only exception is / size).
Also, I recommend using reiserfs for /var. Read ArchWiki pages for a lot of useful info. I never used Ubuntu Wiki, so have no clue of what is there.
Complementing sphynx's answers:
- I have, personally, never heard of any buggy application that fills up /tmp. However, nothing would prevent it.
- The option to specify the size granted to the tmpfs file system is "size". For instance, you can have "size=100M" in the fourth column of /etc/fstab.
- Since you have 4GB of RAM, I wanted to point out that 2GB of swap looks small. Indeed, as far as I know (but it may have changed) the hibernation causes the (compressed) data in RAM to be be transferred to the swap partition. I guess you want to be able to hibernate a system as long as it does not swap. That is why I would recommend 4GB of swap.
@sphynx:
- As far as I know, 'free' is not appropriate to really know how much RAM is used by the processes that are currently running because it reports all the memory managed by the kernel and Linux keeps in RAM the data/programs that have recently been closed (because there is a high probability that they will accessed/run again soon and the disk is slow). You can observe that the GNOME system manager reports smaller values. For instance, on my laptop it currently reports 897MB, whereas 'free' indicates almost 1.6GB.
- I do not get what you mean by "before starting up the system for the first time". Isn't it possible to simply edit /etc/fstab, reboot and then takes care of unused partition?
Indeed, 2 GB swap is few for 4 GB RAM, but I remember reading in ArchWiki Linux someway handles it. (I know Arch isn't fully Free, but its wiki is very good. I would link to Parabola's one instead if it had any equivalent for those pages)
@Magic Banana:
Yes, occupied differs from busy. The "-/+ buffers/cache" line in the output of "$ free" is for that distinction.
And yes, it's possible to boot up the system first and then care about tmpfs in /etc/fstab, but, depending on the partitioning scheme, it could lead to fulfilling the root partition. I prefer to setup all that I can before booting up the system for the first time. Just a matter of method.
Because I was not used to Trisquel, it led me to set a not-that-good size for root partition, but I don't care removing old kernel images. And I just noticed I can fix it by reducing my swap partition's size, which is 168 MiB bigger than my RAM, and then increasing the size of my root partition that much! Iha!
Thank you for teaching me that "-/+ buffers/cache" corresponds to the actual RAM occupation. :-) It indeed corresponds to what GNOME system monitor reports.
apvp's system is already installed so doing things "before booting up the system for the first time" is not an option anymore... or did I misunderstand you? Since you confirm that editing /etc/fstab and rebooting works, it looks like it is the way to go.
I forgot to write about your choice of ReiserFS for /var. This file system is indeed known to be efficiently handling many small files and that is what /var mainly contains. However, and as far as I know, ReiserFS has more or less been left unmaintained for years. That actually is a major explanation for Reiser4 never entering the vanilla Linux kernel (the core developers did not want another file system that would be left unmaintained by its "progenitors"). Using ReiserFS, I would be scared of security issues that may not be fixed.
Just correcting this:
$ free -m
total used free shared buffers cached
Mem: 1879 1479 399 0 12 608
-/+ b/c: 859 1020
I still haven't installed Trisquel. I've just used a liveCD to partition my disk, but I'm going to redo that again because I'm opting to use GPT instead of MBR, like sphynx recommended. Also, I'm going to change partition sizes and make them all primary, since GPT allows it. Will choose another file system for each partition (maybe all ext4... I just won't use JFS because it was developed by IBM), and I will put /tmp in memory... I just need a little explanation on how to edit /etc/fstab before booting the system for the first time. That's all I need to do my thing. I feel like I'm pushing it but, could someone explain how that's done?
Thanks everybody, you've been great!
Choosing ext2 for /boot, which does not need a journal, and XFS for /home, which usually contain large files, definitely makes sense. I do not know what you fear in using IBM's free developments but I have read that JFS is a good file system that lacks love, i.e., it is not popular despite its qualities.
To edit /etc/fstab before the first boot, you must, after the installation completes:
- mount (for instance at /mnt) the file system where it is (i.e., the root file system since you do not seem to want /etc on a separate partition);
- modify, with the administrator privileges (use of 'sudo'), the fstab file with any text editor (gedit seems a natural choice since it already is in the Trisquel's Live system), i.e., if the root file system is mounted in /mnt, this file is /mnt/etc/fstab;
- save and reboot.
If you do not know/want to mount the root file system from the terminal, you can as well, double-click on the related partition you will find in the menu Shortcuts/Desktop (that is a translation from French so it may be different). I believe the root file system will then be mounted in a subdirectory of /media.
But, again, you can as well edit /etc/fstab after booting the newly installed system. That would just make one additional reboot to have /tmp in RAM.
I think I should clarify that my refusal to use IBM's JFS file system has nothing to do with the file system itself, which could even be the best ever in the whole world, but with humanitarian reasons.
Maybe my PC's use IBM parts and I don't even know it, but if I have an option, I'll do the right thing and totally refuse to use it. I think certain things should never be forgotten and everybody should be aware of who's who and who's done what.
If you're curious, ask Edwin Black:
@apvp, @Magic Banana: you're welcome :D
About reiserfs for /var -- yes, it's a good filesystem (improved a lot my pacman performance when I used Parabola, and obviously helps here in Trisquel too), but I never thought about such security problems possibility before. It's a good point.
@apvp: if you didn't setup your system yet, I recommend you, as teodorescup did, to use LVM over LUKS, if you can setup it and learn to use LVM/LUKS. Such configuration provides LVM flexibility within LUKS security. It's possible to do it when installing Trisquel with the text-mode installer (choose it in live CD's boot menu); you can care about separating LVM partitions later if you want.
About it: https://wiki.archlinux.org/index.php/LUKS (See "2 Initial Setup" (remember to securely erase the drive before!) and "2.3.3 How does LVM fit into the overall system?")
https://wiki.archlinux.org/index.php/LVM#Advantages
AFAIK, Trisquel encrypts swap by default, doesn't it? I have the impression of seeing "protected swap" in boot/halt messages a couple of times. Or am I confused and it was Tails?
@sphynx:
I'm sure it was TAILS. I have Trisquel in my desktop too and i had to use cryptsetup to encrypt it. As far as I know, TAILS is the only distro that has(?) swap encrypted by default.
TAILS has an interesting feature that safely erases all RAM when shutting down the PC... I've tried TAILS liveCD in my laptop with 4 GB of RAM and it only took about 6 seconds to erase RAM and power off. Maybe that could be shipped with all distros by default, or, at least, have an option to turn it on/off?? I don't know how "secure" is RAM secure deletion, but I think it wouldn't hurt and it's an added security bonus.
Yes... I do know that RAM is vanished after a few minutes(?) after the PC has been shut down, depending on how hot the boards are, but..... just in case you have a full geared high-tech SWAT team at your door just because you've (mistakingly, of course! Maybe you thought it was already in the public domain - without copyright) downloaded the latest blockbuster movie from some torrent site.... you know.
Maybe that was a lame example... I don't endorse that anyway (doesn't mean I've never done it), but I think that it is the same thing as with proprietary software - the best thing is to drop it altogether. Hollywood just feeds us crap anyway!
I'm having problems installing the system. After giving each partition its mount point and pressing "next" button ubiquity just hangs indefinitely with the status message "Saving installed packages...", as shown in the image in attachment. I think it has something to do with the partitions not mounting.
While ubiquity was hung i tried to mount a USB stick with palimpset and it gave the error message "Daemon is inhibited.". I also noticed that the root partition (/dev/sda2 when locked, /dev/dm-0 when unlocked) was the only one mounted in tmp.tmp.Something, while the others (home, usr, var, opt, usr/local) were unmounted.
These are the commands i used to install the system:
sudo su modprobe sha256 cryptsetup -y --cipher aes-xts-essiv:sha256 --key-size 512 luksFormat /dev/sda2 # Entered passphrase. cryptsetup --cipher aes-xts-essiv:sha256 --key-size 512 luksFormat /dev/sda3 --key-file /path/to/key-file cryptsetup --cipher aes-xts-essiv:sha256 --key-size 512 luksFormat /dev/sda4 --key-file /path/to/key-file # ..........etc............ # cryptsetup luksOpen /dev/sda2 root # Entered passphrase. cryptsetup luksOpen /dev/sda3 home --key-file /path/to/key-file cryptsetup luksOpen /dev/sda4 usr --key-file /path/to/key-file # ..........etc............ # mkfs.ext4 /dev/mapper/root mkfs.xfs /dev/mapper/home mkfs.ext4 /dev/mapper/usr mkfs.ext4 /dev/mapper/var mkfs.ext2 /dev/mapper/opt mkfs.ext2 /dev/mapper/usr-local
and finally ran ubiquity --desktop %k gtk_ui
Didn't get to the rest because ubiquity hanged and Trisquel was not installed.
Is there something wrong/missing in those commands? Any thoughts on why ubiquity hangs? Any help would be much appreciated!
Assuming the message "Saving installed packages..." means something, I would say that the partitioning went right.
I installed a new Trisquel box yesterday and the installer (run through the icon on the Live system's desktop) hung. I tried again without the network (I was sharing the bad Wifi connection though a wire reaching the computer where the system was to be installed) and the installation went right. However I did that because the last message logged was an error reported by NetworkManager, and that is not your case.
When I installed Trisquel in my notebook, I just selected the text-mode installation, choosed the default LVM/LUKS partitioning scheme and everything went fine.
I don't know what's happening, but I /always/ had problems with Ubiquity when trying to do something different. I think it's some KISS curse on me ;P
If the partitioning scheme is complete, try to boot the Live CD again and install Trisquel, hoping it will know what to do... I would suggest the text-mode installer, which have the LVM/LUKS option. Maybe you will only need to give the instructions to the installer.
- Inicie sesión o regístrese para enviar comentarios