luks_activation.md

When there are a lot of encrypted devices, the user is asked to provide the password for every LUKS. This can be very annoying in some typical cases. For example, if the user only wants to activate one device, or if all devices use the same password.

Possible use cases

• Accept password for the current luks
• Accept password for the current luks and try to activate next lukes with the same password.
• Cancel activation of the current luks
• Cancel activation of the current and next lukses

The popup to ask for the password should provide options to cover such use cases.

Proposal 1

Proposal 2

Proposal 3

Proposal 4

This is a simplified version that only allows to skip the rest of encrypted devices, but it does not offer to reuse the password.

Note: This requires support from libstorage-ng to provide the size and label (luks2) of the device.

Proposal 5

Actually this is an alternative/complementary solution. The idea is to preselect what devices to probe. With this, a user could indicate only the device (or devices) for installing/upgrading without bothering with stuff from other devices. As result, the probed devicegraph would only contain the selected devices.

The device selection could offer different filters, for example, by device name, by technology (RAID, multipath, network device, etc).

How to provide this feature? Due to this is a special feature only needed for certain scenarios, it makes sense to activate it by means of a booting parameter like YAST_PRESELECT_DEVICES=1. The Expert Menu could also provide a way to activate it. Once the option is activated, the user would be asked before probing the system. We could use the light probing to inform the user about the available devices. After selecting with devices to probe, that information has to be passed to libstorage-ng in order to limit the probing action.

Caveats:

• The probing with limited devices could report more issues than the regular probing, for example, because incomplete VGs, RAIDs, etc.
• During the upgrade, some fstab devices could not be found if they are not pre-selected.
• During installation, it would not be possible to import some mount points.

Proposal 6

This is the original Martin's idea. It consists on offering a boot parameter to indicate the LUKSes we want to open. The rest of encrypted devices will not be decrypted and the user will not be asked for a password. For example: YAST_OPEN_LUKS=/dev/sda2,/dev/sda3.

BTW the PBI is https://trello.com/c/MvkmdI10

From our IRC channel:

[14:33:32] <jilopez> ancorgs, dgdavid, HuHa: new ideas are welcome ;)
[14:34:23] <HuHa> I wonder how common it is that a user has several encrypted volumes with a different password for each one
[14:34:57] <HuHa> Can we simply try to decrypt everything with the first password entered?
[14:35:02] <HuHa> if that fails, we can ask for more
[14:35:28] <HuHa> it might leave some "auth failed" entries in some logs, though
[14:35:46] <jilopez> HuHa: yes, that is an option, but I am not sure if that is good. Maybe the user only wants to open one for installation
[14:36:37] <jilopez> HuHa: even when "Accept for all" is used, I guess it should stop trying with the first failure and ask again
[14:37:08] <HuHa> jilopez: so maybe do it a bit differently: Ask for one password and add a number of checkboxes (all checked by default) where to apply it
[14:37:34] <HuHa> i.e. make it easy to go the simple way, but leave the more academic options if some user wants them
[14:38:47] <jilopez> [ ] Use this password for all encrypted devices, and [ ] Do not ask again ?
[14:38:52] <HuHa> no
[14:39:00] <HuHa> [ ] /dev/sda1
[14:39:08] <HuHa> [ ] /dev/sda2
[14:39:09] <HuHa> etc.
[14:39:31] <jilopez> I fear we don't know the devices in advance
[14:39:34] <HuHa> or use a selection box (list) or a multi selection box
[14:39:45] <dgdavid> jilopez: checking
[14:39:57] <ancorgs> due to how libstorage-ng probing works, we don't know all the devices in advance
[14:40:02] <HuHa> jilopez: not knowing that in advance would be awkward in every case
[14:40:36] <mvidner> jilopez: "if the user only wants to activate a device" - huh, do you mean ONE device?
[14:40:56] <HuHa> if it's only for HW probing during installation, we could simply try with the last PW the user entered
[14:40:57] <jilopez> mvidner: yes, sorry
[14:41:04] <HuHa> and only ask for a new one if that didn't work
[14:41:31] <HuHa> right now it sounds like optimizing for the pathological case
[14:42:20] <jilopez> HuHa: but again, if the system has 100 lukses with the same password, it does not make sense to open all them if the user only wants to use one device
[14:42:59] <HuHa> that would be a prime example for a pathological case
[14:43:10] <jilopez> jilopez: and maybe activating everything will take long time ? 
[14:43:19] <HuHa> can you imagine that in real life? how many passwords can you memorize?
[14:44:33] <jilopez> HuHa: no, the point is that you use only one password but you don't want to activate your 100 devices
[14:44:58] <jilopez> I guess ancorgs knows better the possible use cases
[14:45:04] <HuHa> I think that's not a real-life use case
[14:45:33] <HuHa> think about it: you'd have to enter those passwords one by one at each reboot
[14:45:41] <HuHa> that sounds quite insane to me
[14:47:16] <jilopez> HuHa: actually not. Maybe you have access to a lot network devices, but your system only needs to open some of them
[14:47:26] <ancorgs> the use-case that originated the card (that may not be the only use-case) was:
[14:47:35] <ancorgs> - They have 96! encrypted disks
[14:48:06] <HuHa> that user really needs professional assistance
[14:48:10] <ancorgs> - They want to activate only the ones that hold the root filesystem
[14:48:14] <HuHa> and I am not talking about a computer hotline ;-)
[14:48:44] <ancorgs> - They want to ignore the rest because they contain data and I assume are activated by any other mean (not entering the password by hand)
[14:49:11] <HuHa> so, if that is a real use case, we need to probe first for LUKS devices, then let the user select which ones to open, and THEN ask for the password(s)
[14:49:37] <ancorgs> https://bugzilla.suse.com/show_bug.cgi?id=1162545
[14:49:44] <HuHa> if that needs a change in libstorage-ng, so be it
[14:49:53] <jilopez> HuHa: but sometimes you need to open devices to discover more encrytion devices
[14:50:18] <HuHa> so it needs to be a recursive process
[14:50:28] <HuHa> (which I believe is an even more unlikely case)
[14:50:45] <HuHa> if one encryption layer could be broken, why would the next one be more difficult to break?
[14:55:23] <mvidner> ancorgs: the part about decrypting only the root fs sounds like guessing
[14:57:38] <HuHa> yes
[14:57:40] <mvidner> have we checked with actual users of many encrypted disks, what their acceptable workflows would look like?
[14:57:49] <HuHa> and they seem to want to make their really weird case the norm
[14:58:01] <mvidner> in the bug it looks like guessing from our PMs
[14:58:43] <mvidner> well what looks weird to us might be the best way given their constraints,
[14:59:03] <mvidner> but since we don't understand it we will very likely design a bad response
[14:59:23] <HuHa> that may be so, but it shouldn't hurt users with more common use cases
[14:59:43] <mvidner> "simple things should be simple, hard things should be possible"
[14:59:53] <HuHa> which would be the case when the possible answers to our question become very complicated
[15:00:02] <HuHa> mvidner: yes, definitely
[15:00:31] <HuHa> that's why I would try to collect the LUKS devices in a first step and then start asking questions
[15:00:43] <HuHa> in most cases it will be 0 or 1, and that's simple to handle
[15:01:18] <HuHa> if it's more, I'd offer a more complex selection - like first selecting which one(s) to try to open
[15:01:35] <HuHa> and offering if the same password should be tried with the other selected ones
[15:01:56] <HuHa> but I wouldn't make that complicated case the normal one
[15:03:09] <HuHa> and I'd accept the risk of finding another LUKS layer inside a LUKS device after decrypting the outer layer
[15:03:26] <HuHa> in that case, the user has to enter another password (how else could that work?)
[15:03:39] <HuHa> but in that case, the user already decided to use that device
[15:03:44] <mvidner> one solution: leave the interactive part as simple as it has been, and allow a boot parameter like encrypted_device=/dev/sda37 encrypted_device=/dev/sda38, which would ignore all other lukses
[15:03:47] <HuHa> it wouldn't make any sense to open the outer layer and then stop
[15:03:58] <HuHa> mvidner: good idea, actually
[15:04:54] <HuHa> jilopez, ancorgs: how about that?
[15:05:56] <mvidner> ... but really check with the reporter that it makes sense for their customer

---

[15:12:55] <ancorgs> may work... but I would prefer something that doesn't need boot parameters
[15:13:15] <ancorgs> in fact, the use case is more about skipping unwanted questions than about opening many devices
[15:13:50] <ancorgs> so I would consider introducing some kind of "ignore other LUKS" checkbox (with better wording and all that, of course)
[15:14:00] <HuHa> a cheap solution would be a "don't ask again for LUKS passwords" button or check box
[15:14:13] <ancorgs> HuHa: exactly
[15:14:18] <HuHa> but if you really want to use /dev/sdc37, you still have a lot of clicking ahead of you...
[15:15:09] <HuHa> choose your poison ;-)
[15:16:12] <ancorgs> I would say that having dozens of encrypted devices and not wanting to activate any of them is a reasonable use case
[15:16:20] <HuHa> pragmatic approach:
[15:16:42] <ancorgs> But having dozens of encrypted disks and wanting to ignore many of them except one or two "in the middle"...
[15:16:43] <HuHa> after asking the 3rd password and being rejected, ask "what device would you like to decrypt?"
[15:17:02] <HuHa> (with a "none" answer, of course)
[15:17:36] <ancorgs> well, that's a quite special case. So they need to skip the first 37. Then provide the password and then click "do not ask me again"
[15:18:16] <ancorgs> I think is reasonable if such a scenario really exists (and is not made up by the consultant in the bug)

The original bug:

https://bugzilla.suse.com/show_bug.cgi?id=1162545