Re: [gentoo-user] Re: tmp on tmpfs
On Thu, May 25, 2017 at 12:28 PM, J. Roeleveldwrote: > > Not sure how long ago this was. I'm planning on redoing the whole laptop in > the near future anyway. > > If anyone knows of a better way (that works without TPM) I would like to hear > about it. > I'd read up on LUKS. That seems to be the way everybody is doing stuff like this today. It probably isn't much different in security but it is more standard, which means more convenience when booting from rescue disks and so on. I bet with something like dracut you can probably configure it more easily as well. However, I've not looked into the details. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On May 25, 2017 6:06:45 PM GMT+02:00, Rich Freemanwrote: >On Thu, May 25, 2017 at 10:16 AM, J. Roeleveld >wrote: >> On May 25, 2017 1:04:07 PM GMT+02:00, Kai Krakow > wrote: >>>Am Thu, 25 May 2017 08:34:10 +0200 >>>schrieb "J. Roeleveld" : >>> It is possible. I have it set up like that on my laptop. Apart from a small /boot partition. The whole drive is encrypted. Decryption keys are stored encrypted in the initramfs, which is embedded in the kernel. >>> >>>And the kernel is on /boot which is unencrypted, so are your >encryption >>>keys. This is not much better, I guess... >> >> A file full of random characters is encrypted using GPG. >> Unencrypted, this is passed to cryptsetup. >> >> The passphrase to decrypt the key needs to be entered upon boot. >> How can this be improved? >> > >The need to enter a passphrase was the missing bit here. I thought >you were literally just storing the key in the clear. > >As far as I can tell gpg symmetric encryption does salting and >iterations by default, so you're probably fairly secure. I'm not sure >if the defaults were always set up this way - if you set up that file >a long time ago you might just want to check that, unless your >passphrase is really complex. Not sure how long ago this was. I'm planning on redoing the whole laptop in the near future anyway. If anyone knows of a better way (that works without TPM) I would like to hear about it. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: tmp on tmpfs
On Thu, May 25, 2017 at 10:16 AM, J. Roeleveldwrote: > On May 25, 2017 1:04:07 PM GMT+02:00, Kai Krakow wrote: >>Am Thu, 25 May 2017 08:34:10 +0200 >>schrieb "J. Roeleveld" : >> >>> It is possible. I have it set up like that on my laptop. >>> Apart from a small /boot partition. The whole drive is encrypted. >>> Decryption keys are stored encrypted in the initramfs, which is >>> embedded in the kernel. >> >>And the kernel is on /boot which is unencrypted, so are your encryption >>keys. This is not much better, I guess... > > A file full of random characters is encrypted using GPG. > Unencrypted, this is passed to cryptsetup. > > The passphrase to decrypt the key needs to be entered upon boot. > How can this be improved? > The need to enter a passphrase was the missing bit here. I thought you were literally just storing the key in the clear. As far as I can tell gpg symmetric encryption does salting and iterations by default, so you're probably fairly secure. I'm not sure if the defaults were always set up this way - if you set up that file a long time ago you might just want to check that, unless your passphrase is really complex. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On May 25, 2017 1:04:07 PM GMT+02:00, Kai Krakowwrote: >Am Thu, 25 May 2017 08:34:10 +0200 >schrieb "J. Roeleveld" : > >> It is possible. I have it set up like that on my laptop. >> Apart from a small /boot partition. The whole drive is encrypted. >> Decryption keys are stored encrypted in the initramfs, which is >> embedded in the kernel. > >And the kernel is on /boot which is unencrypted, so are your encryption >keys. This is not much better, I guess... A file full of random characters is encrypted using GPG. Unencrypted, this is passed to cryptsetup. The passphrase to decrypt the key needs to be entered upon boot. How can this be improved? -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: tmp on tmpfs
On Thu, May 25, 2017 at 7:04 AM, Kai Krakowwrote: > Am Thu, 25 May 2017 08:34:10 +0200 > schrieb "J. Roeleveld" : > >> It is possible. I have it set up like that on my laptop. >> Apart from a small /boot partition. The whole drive is encrypted. >> Decryption keys are stored encrypted in the initramfs, which is >> embedded in the kernel. > > And the kernel is on /boot which is unencrypted, so are your encryption > keys. This is not much better, I guess... > Agree. There are only a few ways to do persistent encryption in a secure way: 1. Require entry of a key during boot, protected by lots of rounds to deter brute force. 2. Store the key on some kind of hardware token that the user keeps on their person. 3. Store the key in a TPM, protected either by: a. entry of a PIN/password of some sort with protections on attempt frequency/total b. verification of the boot path (which should be possible with existing software on linux, but I'm not aware of any distro that actually implements this) If you don't have hibernation then you can just generate a random key on boot, and that is very secure, but your swap is unrecoverable after power-off. Of the options above 3b is the only one that really lets you do this with the same level of convenience. This is how most full-drive encryption solutions work in the Windows world. Chromebooks use a variation on 3a I believe using your google account password as one component of the key and putting it through the TPM to have a hardware component and to throttle attempts. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Thursday 25 May 2017 04:45:24 Martin Vaeth wrote: > Andrew Savchenkowrote: > > For similar needs I found zswap the most suitable, it's so much > > > better than zram: > This sounds like one is an alternative to the other. > This is not the case. It can even make sense to use them together. > For instance, the swap device necessarily required for zswap > can be a zram device. Whether this is advantegous depends on your > usage pattern and swappiness value. Do either of these reduce the effect of (spinning) drive thrashing and desktop latency increasing when swapping takes place? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: tmp on tmpfs
On May 25, 2017 5:38:35 AM GMT+02:00, Kai Krakowwrote: >Am Wed, 24 May 2017 12:30:36 -0700 >schrieb Rich Freeman : > >> On Wed, May 24, 2017 at 11:34 AM, Ian Zimmerman >> wrote: >> > On 2017-05-24 08:00, Kai Krakow wrote: >> > >> >> Unix semantics suggest that /tmp is not expected to survive >reboots >> >> anyways (in contrast, /var/tmp is expected to survive reboots), so >> >> tmpfs is a logical consequence to use for /tmp. >> > >> > /tmp is wiped by the bootmisc init job anyway. >> > >> >> In general I haven't found anything that is bothered by /var/tmp >being >> lost on reboot, but obviously that is something you need to be >> prepared for if you put it on tmpfs. >> >> One thing that wasn't mentioned is that having /tmp in tmpfs might >> also have security benefits depending on what is stored there, since >> it won't be written to disk. If you have a filesystem on tmpfs and >> your swap is encrypted (which you should consider setting up since it >> is essentially "free") then /tmp also becomes a useful dumping ground >> for stuff that is decrypted for temporary processing. For example, >if >> you keep your passwords in a gpg-encrypted file you could copy it to >> /tmp, decrypt it there, do what you need to, and then delete it. >That >> wouldn't leave any recoverable traces of the file. > >Interesting point... How much performance impact does encrypted swap >have? I don't mean any benchmark numbers but real life experience from >your perspective when the system experiences memory pressure? I have my laptop encrypted. Has 16GB and occasionally it does use swap. With it all being on SSD. I am not noticing any slowdowns because of it. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: tmp on tmpfs
It is possible. I have it set up like that on my laptop. Apart from a small /boot partition. The whole drive is encrypted. Decryption keys are stored encrypted in the initramfs, which is embedded in the kernel. -- Joost On May 25, 2017 12:40:12 AM GMT+02:00, Rich Freemanwrote: >On Wed, May 24, 2017 at 2:16 PM, Andrew Savchenko >wrote: >> >> Apparently it is pointless to encrypt swap if unencrypted >> hibernation image is used, because all memory is accessible through >> that image (and even if it is deleted later, it can be restored >> from hdd and in some cases from ssd). >> > >Yeah, that was my main concern with an approach like that. I imagine >you could use a non-random key and enter it on each boot and restore >from the encrypted swap, though I haven't actually used hibernation on >linux so I'd have to look into how to make that work. I imagine with >an initramfs it should be possible. > >-- >Rich -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Re: tmp on tmpfs
On Wed, May 24, 2017 at 2:16 PM, Andrew Savchenkowrote: > > Apparently it is pointless to encrypt swap if unencrypted > hibernation image is used, because all memory is accessible through > that image (and even if it is deleted later, it can be restored > from hdd and in some cases from ssd). > Yeah, that was my main concern with an approach like that. I imagine you could use a non-random key and enter it on each boot and restore from the encrypted swap, though I haven't actually used hibernation on linux so I'd have to look into how to make that work. I imagine with an initramfs it should be possible. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Wed, 24 May 2017 12:30:36 -0700 Rich Freeman wrote: > On Wed, May 24, 2017 at 11:34 AM, Ian Zimmermanwrote: > > On 2017-05-24 08:00, Kai Krakow wrote: > > > >> Unix semantics suggest that /tmp is not expected to survive reboots > >> anyways (in contrast, /var/tmp is expected to survive reboots), so > >> tmpfs is a logical consequence to use for /tmp. > > > > /tmp is wiped by the bootmisc init job anyway. > > > > In general I haven't found anything that is bothered by /var/tmp being > lost on reboot, but obviously that is something you need to be > prepared for if you put it on tmpfs. > > One thing that wasn't mentioned is that having /tmp in tmpfs might > also have security benefits depending on what is stored there, since > it won't be written to disk. If you have a filesystem on tmpfs and > your swap is encrypted (which you should consider setting up since it > is essentially "free") then /tmp also becomes a useful dumping ground > for stuff that is decrypted for temporary processing. For example, if > you keep your passwords in a gpg-encrypted file you could copy it to > /tmp, decrypt it there, do what you need to, and then delete it. That > wouldn't leave any recoverable traces of the file. > > There are lots of guides about encrypted swap. It is the sort of > thing that is convenient to set up since there is no value in > preserving a swap file across reboots, so you can just generate a > random key on each boot. I suspect that would break down if you're > using hibernation / suspend to disk. It is easy to use both encrypted swap and encrypted hibernation image (I do this on my laptop). Just before s2disk call disable swap completely, then create empty unencrypted swap and run s2disk (swappiness may be disabled to protect from accidental write of unencrypted data before fresh swap creation and s2disk call). Afterwards s2disk may be used to create encrypted memory image and store it in the swap partition. On resume just reverse actions. Apparently it is pointless to encrypt swap if unencrypted hibernation image is used, because all memory is accessible through that image (and even if it is deleted later, it can be restored from hdd and in some cases from ssd). Best regards, Andrew Savchenko pgpHK8m7gAlj4.pgp Description: PGP signature
Re: [gentoo-user] Re: tmp on tmpfs
On Wed, May 24, 2017 at 11:34 AM, Ian Zimmermanwrote: > On 2017-05-24 08:00, Kai Krakow wrote: > >> Unix semantics suggest that /tmp is not expected to survive reboots >> anyways (in contrast, /var/tmp is expected to survive reboots), so >> tmpfs is a logical consequence to use for /tmp. > > /tmp is wiped by the bootmisc init job anyway. > In general I haven't found anything that is bothered by /var/tmp being lost on reboot, but obviously that is something you need to be prepared for if you put it on tmpfs. One thing that wasn't mentioned is that having /tmp in tmpfs might also have security benefits depending on what is stored there, since it won't be written to disk. If you have a filesystem on tmpfs and your swap is encrypted (which you should consider setting up since it is essentially "free") then /tmp also becomes a useful dumping ground for stuff that is decrypted for temporary processing. For example, if you keep your passwords in a gpg-encrypted file you could copy it to /tmp, decrypt it there, do what you need to, and then delete it. That wouldn't leave any recoverable traces of the file. There are lots of guides about encrypted swap. It is the sort of thing that is convenient to set up since there is no value in preserving a swap file across reboots, so you can just generate a random key on each boot. I suspect that would break down if you're using hibernation / suspend to disk. -- Rich