Bug 1043410

Summary: yast2-users: drop cryptconfig support (Encrypted home directory)
Product: [openSUSE] openSUSE Tumbleweed Reporter: Jan Matejek <jmatejek>
Component: YaST2Assignee: YaST Team <yast-internal>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: dutchkind, fcrozat, jsrain, locilka, mfilka, tchvatal
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://trello.com/c/g6yaR6qU
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Screenshot of the feature
Screenshot: "Details" page of "Add new user" in Leap 15.4

Description Jan Matejek 2017-06-08 14:02:07 UTC 
Yast's Encrypted home directory feature was introduced in fate#253 (yes, that low). The stated purpose was to support a scenario where you don't want to use FDE but still want some measure of protection.

This was implemented by creating an encrypted loopback device and mounting it to the user's home directory at login time through PAM. For supporting the configuration, we have a homebrew tool called 'cryptconfig'.
https://github.com/openSUSE/cryptconfig

The tool is not developed anymore, assumed mostly broken, and AFAICT this feature hasn't worked as far back as SLE 11.

We propose to drop the cryptconfig tool from the distribution and remove support from yast2-users.

Rationale:
* The method of choice doesn't make much sense from a security standpoint. Encrypted data is only protected when the user is logged off, and only from non-root users (root has the power to steal passwords at login) -- which is something standard Unix permissions should normally guarantee you as well. Maybe for data-at-rest (stolen laptop scenario) this is helpful, but that case is covered by FDE.
* Using loopback devices sets a limit on the size of the home directory. More modern methods, such as ecryptfs, allow the home directory to take up as much space as it requires.
* Cryptconfig is an in-house tool with no community support, and we don't have resources for necessary further development. It is slowly bitrotting away, relying on deprecated PAM modules etc.

Replacements:
* just use FDE
* or implement instead ecryptfs support. According to [1], configuring ecryptfs on SUSE is as simple as installing a package. ecryptfs is also in active development and solves many issues with the security of encrypted loopback devices
Comment 2 Lukas Ocilka 2017-06-19 08:34:49 UTC 
Jiri, Stefan: This is basically a feature request, but the result would be feature removal. On the other hand, a feature, that does not make sense
(see explanation above).

What do you think?
Comment 3 Lukas Ocilka 2017-06-19 08:35:18 UTC 
Created attachment 729342 [details]
Screenshot of the feature
Comment 4 Jiri Srain 2017-06-19 08:42:41 UTC 
Hmm, removing the tool completely, what about upgrade path?

In any case, especially because of upgrade (leaving aside the note about being broken), this needs proper documentation including RN entry, informing users what to do before upgrade not to loose the data (or spend time restoring from backup), therefore from my PoV we need a Fate entry.
Comment 5 Stefan Behlert 2017-06-19 08:53:04 UTC 
Definitely something that needs a FATE, and an agreement across the various stakeholders. I cannot say when it got broken, but apparently it worked some time ago in SLE 11.


I'm not convinced we cna drop the tool completely, as the upgrade is a topic. People using 15 need a way to access the stuff in their old homes. There are several ways we could provide, but that should be discussed in the feature.
Comment 6 David Kerkhof 2018-02-08 13:07:04 UTC 
I came across this page because this morning I had to fsck my encrypted home after some update problems with plasma on tumbleweed and I realized cryptconfig had gone.

This is sad since it worked still for me. I understand the reasoning of not having the resources to maintain this package but I tend to disagree about the security issues.

For me FDE is overkill and complicated to implement on a multiboot system without having to reinstall everything from scratch.
Having an encrypted home is useful to protect a users private stuff as you mention, in case of theft. That is an important issue for me, and maybe more users. Documents and that kind of stuff are easily encrypted using luks or veracrypt, but the user's home not that easy.

Unless you mean there is an easy way to migrate to ecryptfs. I just installed the package but no option in yast which would make it much easier so I will have to sort that out. But please be considerate that there are still users using encrypted homes!
Comment 7 Stefan Hundhammer 2023-03-08 13:12:54 UTC 
Created attachment 865369 [details]
Screenshot: "Details" page of "Add new user" in Leap 15.4

Notice no checkbox for encryption of the home directory.
Comment 8 Stefan Hundhammer 2023-03-08 13:14:32 UTC 
AFAICS this has already been removed during one of the refactorings during the 5 years since this bug was filed.

Closing.