Re: [gentoo-user] Re: tmp on tmpfs

[Rich Freeman]

On Thu, May 25, 2017 at 12:28 PM, J. Roeleveld  wrote:
>
> 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

[J. Roeleveld]

On May 25, 2017 6:06:45 PM GMT+02:00, Rich Freeman  wrote:
>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

[Rich Freeman]

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.

-- 
Rich

Re: [gentoo-user] Re: tmp on tmpfs

[J. Roeleveld]

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?

--
Joost

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: tmp on tmpfs

[Rich Freeman]

On Thu, May 25, 2017 at 7:04 AM, 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...
>

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

[Mick]

On Thursday 25 May 2017 04:45:24 Martin Vaeth wrote:
> Andrew Savchenko  wrote:
> > 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

[J. Roeleveld]

On May 25, 2017 5:38:35 AM GMT+02:00, Kai Krakow  wrote:
>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

[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.

--
Joost

On May 25, 2017 12:40:12 AM GMT+02:00, Rich Freeman  wrote:
>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

[Rich Freeman]

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

Re: [gentoo-user] Re: tmp on tmpfs

[Andrew Savchenko]

On Wed, 24 May 2017 12:30:36 -0700 Rich Freeman wrote:
> 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.
> 
> 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

[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.

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