swap presence should stop blocking operations

[jaromil]

it is way too extreme to stop operations for the presence of swap; this behavior wasn't even discussed.

OTOH the swap vulnerability counts.

tomb runs as root so it could check for presence of a swap and execute swapoff/on -a

until this is implemented we cannot block the operation, but in case print out a warning.

[boyska]

I don't agree, as our goal is to provide the user with security out of the box. Users wil read the warning only after their security has been compromised.

The swapoff -a solution is problematic, as we've discussed: swapoff -a may lead to system hanging for minutes (reading data from swap) or even crashing completely (if the ram isn't enough).

However, I have an idea: see #38 and please give your opinion on that. I think that is the final solution of the problem

[jaromil]

ok, as discussed on IRC, considering that an active swap might disclose tomb's contents during its use, a scenario i didn't consider before, i think now that it is reasonable to enforce this behaviour.

even using mlock doesn't solves this problem....

[eloyesp]

The swapoff -a solution is problematic, as we've discussed: swapoff -a may lead to system hanging for minutes (reading data from swap) or even crashing completely (if the ram isn't enough).

Could you ask about doing that instead of just suggesting that? That will add some usability (and prevent some typing) while making sure that the user know what's happening.

tomb [W] This poses a security risk.
tomb [W] You can deactivate all swap partitions using the command:
tomb [W]  swapoff -a
tomb [W] Should I do that for you (it may take a while) (Y/n):

Also a setting for always doing that would be awesome.

[hellekin]

On 06/09/2016 03:13 AM, Eloy Espinaco wrote:

Could you ask about doing that instead of just suggesting that?

I don't think it's a good idea:

1. swapping off safely is not a simple task
2. swapping off is a task that doesn't belong to tomb's scope
3. making users lazy and uninformed is not the goal of the program

If you have good reason to use unencrypted swap (hint: you probably don't) it's not Tomb's call, but yours. If you want security, you shouldn't use clear swap, and tutorials abound to encrypt your swap, that take less time and effort than coding a proper solution for all cases.

[eloyesp]

Ok, didn't know about that.

On the other hand if the recommended approach is encrypting the swap, the hint should say something about it (besides teaching swapoff -a), that should be possible as is just changing the error message. in https://github.com/dyne/Tomb/blob/master/tomb#L332

[jaromil]

Tomb has no interactivity by an agreed design choice, so that it can be used safely in shell scripts. In the few cases of interactivity the use of --force is suggested to confirm, as also in this case.

[eloyesp]

Why not add a note with a link about encrypting the swap (like https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions). (For the record, encrypting the swap is not that easy.)

--- Eloy

2016-06-09 10:27 GMT-03:00 D.J.R. notifications@github.com:

Tomb has no interactivity by design choice, so that it can be used in shell scripts. In the few cases of interactivity the use of --force is suggested to confirm, as also in this case. We may eliminate the swapoff -a recommendation and just leave the possibility to --force.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dyne/Tomb/issues/44#issuecomment-224893841, or mute the thread https://github.com/notifications/unsubscribe/AAKm5V-nrSx_pUzVAVHUMY1M4THSsu1lks5qKBTCgaJpZM4IxmJo .