Right.
https://bugs.launchpad.net/bugs/1799550 has been opened in 2018 to track
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 <
1773...@bugs.launchpad.net> a écrit :
> The issue reported here is that
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
No it is not a grub issue. It's an issue with the installer which does not
provide this option anymore. Wishlist..kind of but I think it is much
closer to a big security issue than to a wishlist. The net result is that
people do install kubuntu without any encryption.
Le mar. 22 déc. 2020 à 19:40
This doesn't look like it'll ever be done. Based on past experience, I
don't think that Canonical takes encryption seriously.
So, I've thrown in the towel. Since buying a new computer, I haven't
used dual-boot. Instead, I installed Ubuntu using its full-disk LUKS
encryption. I run Windows in a VM
** Changed in: grub2 (Ubuntu)
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption needs to be supported out-of-the-box including
Well it's an issue indeed but the fact that no encryption is possible
without having to deal with the command line is much worst.
Le lun. 21 déc. 2020 à 22:15, Nodøn <1773...@bugs.launchpad.net> a écrit
:
> Encryption should also be possible without LVM. LVM is very good, but if
> you are using f
Encryption should also be possible without LVM. LVM is very good, but if
you are using for example BTRFS, you may don't want to use both at the
same time. Should just be an option.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
Sad story.
This bug should be critical as it has large security impact. Encryption should
be the norm.
It shall be possible to install an encrypted (k)ubuntu without being techy.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Any updates on this? This is really critical in my opinion. My user
case:
- I work in a large, 1st rank university.
- Unfortunately, moronic administration decides that the default system
is mac, or if specific programs needed Windows, for laptops (we have
RedHat desktop PCs though).
- However,
** Description changed:
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 th
TJ's howto from comment #47 is much better as it allows installing
directly to the target disk, mine needs you to install it to a second
disk and copies over to the target disk.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://b
@tomreyn — Tom, thank you for posting this. I have added it to these three
documents:
https://help.ubuntu.com/community/ManualFullSystemEncryption
https://ubuntuforums.org/showthread.php?t=2399092
https://help.ubuntu.com/community/FullDiskEncryptionHowto
--
You received this bug notification bec
TJ wrote this:
https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption needs to be supported out-of-the-
@jjakob — Jernej, thank you for this useful and important information. I have
included your link in the instructions:
https://help.ubuntu.com/community/ManualFullSystemEncryption
https://ubuntuforums.org/showthread.php?t=2399092
--
You received this bug notification because you are a member of U
By the way, PureOS has the same bug, so I think it goes all the way up to
Debian.
Here's a guide I created on how to move a unencrypted install to fully
encrypted (works with Ubuntu as well):
https://github.com/jjakob/wiki/wiki/Migrating-an-unencrypted-PureOS-
Debian-install-to-fully-encrypted
My attempts to install 20.04 beta desktop or 18.04 LTS netinstall expert
mode with full disk LUKS encryption failed.
1. Tried installing 20.04 Desktop ISO:
- selected manual partitioning
- created a single partition spanning the entire disk
- created a volume for encryption on the partition (LUKS)
+1 to have a full disk encryption (boot+root+swap+home) in the next
Ubuntu release out of the box.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption needs to be sup
Any chance to see a fix in 20.04?
We need to be able to encrypt (k)ubuntu data when ubuntu is installed alongside
windows.
/home encrytion was not perfect but it was better than nothing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
+1. Fortunately I rarely have to use Windows, but I still do have to use
it sometimes for work and study, and as such must maintain a dual boot
on all of my systems. Please implement the fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
+1 to this issue. My new work laptop only has one drive. We require
Windows for some tasks but Linux for others. Full drive encryption is
mandatory for laptops and other portable devices.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
+1 on this issue. Win 10 is required in my work environment, but not for
*everything*; I can use Ubuntu for most of my work, but whole disk
encryption *is* an absolute requirement. I've primarily used Ubuntu for
more than a decade, and would much prefer to keep using it as my daily
OS, but this is
The issue remains the same with 19.10 (beta I tried yesterday).
The 19.10 Kubuntu installer cannot install an encrypted kubuntu in dual boot
with e.g. windows10.
It is still possible to setup such an encrypted kubuntu but it requires
to chroot after the installer has finished its job and to confi
Agreed.
"Full-system encryption needs to be supported out-of-the-box" full system shall
mean 'the Linux partitions' an not 'the full disk'.
In 19.04 it is not possible to install an encrypted kubuntu in dual boot with
windows10 without playing with the command line.
It means that no users new t
Definitely, /boot should be encrypted. It has been proven possible, so
there's every reason to do so.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption needs to be
Any change to be able to install an encrypted Ubuntu 19.10 alongside of a win10?
I don't know if /boot should be encrypted but not being able to encrypt
anything out of the box in 19.04 is a security regression. Crypaetup may not be
perfect but it used to be good enough in many usecases.
--
You
** This bug is no longer a duplicate of bug 1514120
Ubiquity needs to not disable the LVM and encryption options for dual boot
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-sy
*** This bug is a duplicate of bug 1514120 ***
https://bugs.launchpad.net/bugs/1514120
I would like to support this bug report from the perspective of a security
oriented, pragmatic user, likely the kind of which there are plenty out there.
Ubuntu's great success has been and will be based
*** This bug is a duplicate of bug 1514120 ***
https://bugs.launchpad.net/bugs/1514120
** Tags added: bionic cosmic
** This bug has been marked a duplicate of bug 1514120
Ubiquity needs to not disable the LVM and encryption options for dual boot
--
You received this bug notification beca
On 9/7/2018 3:06 AM, Paddy Landau wrote:
> If you are arguing that /boot shouldn't be encrypted, this is a direct
> contradiction of what you wrote earlier that malware can be loaded into
> the ESP; so why couldn't malware be loaded into /boot?
It can. Encrypting it does not stop that.
> Please
> Encryption is for data privacy and as I said before, nothing you consider
> private should be in /boot.
Well, not entirely correct. Encryption is also for tamper resistance, so it is
still very useful even if nothing in /boot is private.
--
You received this bug notification because you are
Phillip, the goal is BOTH secure boot AND encryption. This bug report
specifically deals with the latter, not the former. Why are you so
against encryption? I don't understand!
In the EU, GDPR is law, and in the rest of the world, encryption is
pretty much already de rigueur.
If you are arguing t
If your goal is secure boot, then you need signature verification.
Encryption is not required for that. Encryption is for data privacy,
and as I said before, nothing you consider private should be in /boot.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
@psusi Yes, that's correct, and should be done in addition to this
request. In other words, both are necessary.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption ne
What you are talking about is signature verification. You need the
firmware to verify the signature on the kernel and initrd, using a
custom self signing key only. That is unrelated to whether /boot is
encrypted or not.
--
You received this bug notification because you are a member of Ubuntu
Bu
@Jonathan Polom (s0nic0nslaught)
Thank you for the extra information.
The full-system encryption linked in the OP solves the part about /boot
being accessed, which is a good thing.
That leaves only three parts to be solved.
1. The error with Grub, which has been reported:
https://bugs.launchpad
I meant to add this in my preceding comment.
This is an example implementation of signed kernel and initramfs for
Ubuntu: https://github.com/Phant0mas/ubuntu-secure-boot
Unsure if it works with 18.04, but this method could be implemented
natively.
--
You received this bug notification because y
I am with Paddy on this one. This isn't a "nice to have" feature but an
essential feature that any operating system with even a sliver of hope
of enterprise-wide adoption needs to support in the second decade of the
21st century. Windows has the benefit of fully supporting TPM based
encryption and
** Description changed:
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 th
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full
@Dimitri Thanks for your comments. I understand where you are coming
from.
I do think, however, that as Ubuntu is intended (and was intended right
from day 1) to be "for human beings", it would make hugely more sense to
support full-system encryption from the installer. People don't want to
be mes
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full
The source package for the current version of GRUB used in Ubuntu is
grub2; reassigning.
** Package changed: grub (Ubuntu) => grub2 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Titl
If you want to preserve other OS and setup encrypted partitions by hand,
you can do so, since forever using the mini.iso d-i installer, and
install ubuntu-desktop task.
yes unencrypted /boot is currently a limitation with grub, but you can
use sicherboot package to boot UEFI based systems securel
@Phillip
I believe that in the heat of the argument the key point was lost.
In the enterprise world, the "desktop" method of "lets assume we can
wipe all user data" and "lets assume this is a single-disk use case"
simply do not add up.
For me, the current model is simply unusable for 2 fundament
I have just discovered that home-folder encryption has been removed from
Ubuntu because, it seems, it is considered buggy and under-maintained.
Full-disk encryption is recommended as an alternative.
Reference:
https://www.linuxuprising.com/2018/04/how-to-encrypt-home-folder-in-ubuntu.html
As you
Sorry, Phillip, yes, you're right about the ESP space — more like
100Mb. I was typing incorrectly; what I meant was at most 400Mb.
I'll look at the ubuntu-devel mailing list and post there. But that
still doesn't obviate this request.
--
You received this bug notification because you are a memb
On 6/22/2018 9:35 AM, Paddy Landau wrote:
> Sorry, no, that's not why I raised this bug report, Phillip. There
> definitely *is* a point in preventing someone from sneaking into your
> office (say, over the weekend), and loading malware in order to either
> modify or steal your data. This type of e
> The point is to prevent people from getting your data if they steal
your computer, not to prevent them from modifying the computer.
Sorry, no, that's not why I raised this bug report, Phillip. There
definitely *is* a point in preventing someone from sneaking into your
office (say, over the weeke
On 6/21/2018 11:57 AM, Paddy Landau wrote:
> If we were to accept your argument, we would say that there is no point
> whatsoever in encrypting anything, and we should eliminate the current
> option to encrypt the home folder when installing Ubuntu.
No; it is not that there is no point; it is that
Phillip, I think that you need to take this discussion to somewhere like
Ubuntu Forums.
If we were to accept your argument, we would say that there is no point
whatsoever in encrypting anything, and we should eliminate the current
option to encrypt the home folder when installing Ubuntu.
This app
Who cares *where* the malware is? Encryption doesn't stop someone from
compromising the machine. You can boot the machine from a USB stick,
then boot the hard disk in a virtual machine, let it look like it is
running normally for you to come put your password in to decrypt the
disk, and the malwa
Yes, I know this, Philip, but unlike with the current setup (where you
can add malware to root and the kernel), with this method, the only
thing that they can change is the ESP (EFI System Partition), because
everything else is fully encrypted in a single partition using LVM
within LUKS.
They can'
That does not stop someone plugging in a usb stick and booting the
machine with malware there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption needs to be support
Phillip, you are correct only if the software partitions are unencrypted
(as is the case with the existing default method). This bug report is
about fully encrypting the entire system — that's everything, including
swap and both root and /boot.
--
You received this bug notification because you ar
Encryption does not stop someone from writing to the disk and putting
different software on it. It just stops them from being able to read
your data.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773
Phillip, do you feel that malware cannot be loaded onto /boot? If you
are right, that would take me by surprise!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Full-system encryption n
What do you mean by "attack vector"? /boot does not contain any
sensitive files that you would want to protect from an attacker.
** Changed in: ubiquity (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Oliver, another point that I missed in my previous comments is that the
full-disk encryption that Ubuntu uses does not play nicely with other
systems. E.g., if you have Windows (true of most users), it will delete
the entire Windows system plus its data.
The instructions given in the above report
Oliver, I've amended the title (the body of the report already says so).
I don't know how to change it to "wishlist", although really, as I say,
in today's world, it is nearly approaching a legal requirement (at least
in the EU because of GDPR) than merely a wish.
** Summary changed:
- Full-syste
then you shoud probably adjust the bug title to something like "full
disk encryption should also encrypt /boot" and mark it as "whishlist"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1773457
Title:
Thank you, Oliver. That link was in fact one of the (many) reference
pages used in creating the instructions. Unfortunately, it isn't
actually full system encryption: /boot isn't encrypted, which allows for
a clear attack vector.
--
You received this bug notification because you are a member of U
full disk encryption is in the installer since several years (i think
since 2012 but i might mis-remember) already ... see some howto site
like: https://linoxide.com/ubuntu-how-to/two-methods-to-protect-your-
data-using-ubuntu-disk-encryption/
--
You received this bug notification because you are
62 matches
Mail list logo