|
Bugzilla – Full Text Bug Listing |
| Summary: | Automatically add a custom generated key to initrd when installing to LVM/LUKS | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Alexander Shchadilov <alexander.shchadilov> |
| Component: | Installation | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED NORESPONSE | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | aschnell, jsrain, nwr10cst-oslnx, security-team, snwint |
| Version: | Leap 15.1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Alexander Shchadilov
2019-06-01 20:02:54 UTC
This has been frequently requested. But please be aware that the security drawback is that in the running system, the keyfile would be readable in plain from /boot. Not a good idea. The better solution is the implementation in grub that allows it to pass the passphrase to the booted system without it appearing in plain in the kernel command line or the logs. This request should be closed. I am opposed to this, as a security risk. Yes, the "initrd" file is normally only readable by root. However, if I install Xen support, then the "initrd" is copied into the EFI partition where it is more easily readable by anyone. (In reply to Andreas Stieger from comment #1) > [...] But please be aware that the security drawback is that in the > running system, the keyfile would be readable in plain from /boot. Is that any worse than being able to use the --showkeys option of dmsetup? I confess I use a setup similar to the proposed myself. The usability of the current default setup is less than optimal, to put it mildly. And that's not even counting the grub behavior on entering a wrong password. If there's any intention to encourage people to use encryption this seems counterproductive to me. I haven't seen any convincing argument as to why storing the password in an encrypted initrd is a security risk. As Arvin pointed out root can access the LUKS decryption keys anyway. And unless you have special crypto hardware that's by design. We've had fate#320901 open for the better part of 3 years without anything coming of it. Which is really a sad state. If anything we should at least give the user the *choice* to go for a user-friendly setup like the proposed. That the initrd gets inadvertently copied to a nonencrypted partition is indeed a risk and we should help the admin to prevent this, if possible. In any case this needs some strategic decisions and someone driving this. Jiri? Security team should look at the proposal. There is another option: Have /boot outside the encrypted volume as a separate partition. Then you need to enter the password only once. However, if you want to use snapper, then you kernel/initrd cannot be snapshotted. What I wanted to point out: It is not possible to put the key there unconditionally even if we accept the risk. In any case: The installer should not implement this request before it gets blessing from the security team. If the design is evaluated as not bringing any additional not acceptable risk, then IMO any approach that improves the usability will be welcome (by myself too). Security team is in NEEDINFO, let them evaluate this idea. This actually needs JIRA entry and everyone involved to design and discuss it there (please). (In reply to Lukas Ocilka from comment #8) > This actually needs JIRA entry and everyone involved to design and discuss > it there (please). That is SUSE internal, so no involvement of the community required on this I guess. The request at the end will need to go through JIRA. Gathering opinions should stay here. No response for 5 months. Closing. For anyone interested: I submitted Andreas Stieger's suggestion from https://bugzilla.suse.com/show_bug.cgi?id=1137056#c1 to GRUB bug tracker: https://savannah.gnu.org/bugs/?57678 |