FS#15257 - [initscripts] Implement an encrypted /tmp in crypttab
Attached to Project:
Arch Linux
Opened by John Piel (uberGeek) - Thursday, 25 June 2009, 06:35 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 22:02 GMT
Opened by John Piel (uberGeek) - Thursday, 25 June 2009, 06:35 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 22:02 GMT
|
Details
Description:
Implement an encrypted /tmp in crypttab, similar to the way the encrypted SWAP is implemented. I have it working on one of my systems now, and I've attached the patches. They need to be reviewed by someone smarter than me, and hopeful implemented :) Thank you Arch Devs! |
This task depends upon
Closed by Tom Gundersen (tomegun)
Sunday, 27 March 2011, 22:02 GMT
Reason for closing: Won't implement
Additional comments about closing: See my last comment.
Sunday, 27 March 2011, 22:02 GMT
Reason for closing: Won't implement
Additional comments about closing: See my last comment.
Unfortunately things got a bit more complicated, because it turned out that there is a bug in the init script which causes the random seed to be restored after the encrypted partitions are set up.
This means that the patch will have to be modified after http://bugs.archlinux.org/task/17131 has been fixed.
The best idea I have on how to fix this right now is to manually set it up in rc.sysinit instead of using /etc/fstab, but I don't like that solution.
Mount a tmpfs filesystem on /tmp. For example, put in /etc/fstab:
tmpfs /tmp tmpfs mode=1777 0 0
It will be swapped out to your encrypted swap as RAM space is needed. In comparison, with an encrypted /tmp partition, Linux will buffer data and delay writing to disk, and Linux will cache data from disk when there is spare RAM or it was recently needed. This amounts to nearly the same thing (except I think with a physical partition, Linux is more aggressive about writing to disk -- which is useless in this case, because once your machine shuts down or crashes, you can't recover the randomly generated key anyway).
If you want tmpfs to be limited to a particular megabyte/gigabyte size, use the size= mount parameter (the default is half the size of physical RAM) -- see `man mount`.
by the way, this is mentioned in less detail on the wiki at http://wiki.archlinux.org/index.php/Maximizing_performance#Mounting_.2Ftmp_to_RAM
If you have no swap at all (horrors!), then I can see encrypted /tmp having a place...
Also, in http://bugs.archlinux.org/task/11648 , Oct. 2009, Thomas Bächler (brain0) says that he's redesigning crypto initscripts to have more flexibility than the crypttab syntax. Should we wait and see?
(slightly off-topic) I thought of the task of generalizing crypto support. For myself, currently I don't use crypttab, just a script I run manually and enter my password; and there is about one other setup I think of wanting personally. For a sane generalization (whole distro's crypto scripts), I'd need to gather as many users' desired use cases as possible first, and then try and fit them. (mailinglist, plus something can be gleaned from the set of crypto initscrip bug-reports...)
If anyone is interested in helping out with the crypto support, please take it to the <arch-projects@archlinux.org> mailinglist. I would suggest having a look at how this is done in systemd, afaik they base what they do on what is done in debian. I think it would make a lot of sense to try to coordinate this effort with other distros.