© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Right.
https:/
the dual boot issue. This is the security issue I was referring to. Sorry
for the confusion.
Le mar. 22 déc. 2020 à 22:30, Julian Andres Klode <
<email address hidden>> a écrit :
> The issue reported here is that /boot is not encrypted in the supported
> configurations. Which is meh - we don't have much authenticated
> encryption, so boot can still be manipulated. Sealed TPM measurements
> address the problem of verifying the bootloader, kernel, initrd, and the
> configuration better. It does not provide security by obfuscation as
> encryption does, but that obfuscation can be circumvented - you can
> modify an encrypted boot partition and still get a working system - and
> authenticated encryption that would also authenticate the content is not
> stable yet.
>
> I cannot say much on the other issue raised in recent comments on dual
> boot setups not installing encrypted, but I fail to see how it's related
> to this bug report
>
> I do want to point out that with devices now being sold with BitLocker
> out of the box, that you do have to disable BitLocker first to even get
> the ability to install another OS, so I fail to see how that improves
> the situation for dual boot users who need encryption.
>
> But in any case adding comments to bugs that are unrelated to the bug is
> not really helpful, you end up with nobody knowing what people are
> talking about anymore.
>
> Hence my suggestion would be to open a new bug report against ubiquity
> describing the dual boot setup issues so that that can be tracked on its
> own and we don't have to discuss two bugs in one bug report.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Full-system encryption needs to be supported out-of-the-box including
> /boot and should not delete other installed systems
>
> Status in grub2 package in Ubuntu:
> Confirmed
> Status in ubiquity package in Ubuntu:
> Confirmed
>
> Bug description:
> In today's world, especially with the likes of the EU's GDPR and the
> many security fails, Ubuntu installer needs to support full-system
> encryption out of the box.
>
> This means encrypting not only /home but also both root and /boot. The
> only parts of the system that wouldn't be encrypted are the EFI
> partition and the initial Grub bootloader, for obvious reasons.
>
> It should also not delete other installed systems unless explicitly
> requested.
>
> On top of this, the previous method of encrypting data (ecryptfs) is
> now considered buggy, and full-disk encryption is recommended as an
> alternative. Unfortunately, the current implementation of full-disk
> encryption wipes any existing OS such as Windows, making the
> implementation unusable for most users.
>
> Now, using LUKS and LVM, it is already possible to have full-disk
> encryption (strictly, full-partition encryption because it leaves any
> existing OS alone), while encrypting /boot. Reference:
>
> https:/
>
> ... but with one major limitation: Grub is incorrectly changed after
> an update affecting the kernel or Grub, so that a manual Grub update
> is required each time this happens (this is fully covered in the
> linked instructions).
>
> If the incorrect Grub change is fixed, it should be (relatively)
> simple to support full-system encryption in the installer.
>
> Further information (2018-08-17):
>
> The NCSC recommends, "Use LUKS/dm-crypt to provide full volume
> encryption."
> References:
> •
> https:/
> • https:/
>
> **EDIT**
> Refer to comment #47 for an alternative version.
>
> To manage notifications about this bug go to:
> https:/
>