Announcement

Collapse
No announcement yet.

Ubuntu 23.10 Beta Released - Powered By Linux 6.5, GNOME 45 & Other Updates

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by wertigon View Post

    This sounds awesome until you realise there will be no security updates until you install the next version of the OS. I don't think the world is ready for this by a long shot.
    Immutability makes most sense with IoT or consumer devices. ChromeOS and Android come to mind. For my workstation, I would rather stick with a traditional Unix-like system. Ubuntu will probably create another flavor with immutability while keeping the main distribution as it is. Otherwise I can easily switch to some other distribution. So nothing to worry about.

    Comment


    • #12
      Originally posted by Eirikr1848 View Post
      TPM based full disk encryption is HUGE for Ubuntu in healthcare environments.

      Cerner for example uses Ubuntu but only on patient monitor displays that do not store data.
      When one of those Ubuntu devices has a motherboard issue. How would the admin switch to another machine having a different TPM module?

      Maybe in the case you mentioned, the devices are stateless and there is no harm to reinstall from scratch. My question is more generic:

      What is the mitigation approach to reuse the the content of a TPM-based encrypted disk when the motherboard is replaced?

      Comment


      • #13
        Originally posted by Mirox View Post

        When one of those Ubuntu devices has a motherboard issue. How would the admin switch to another machine having a different TPM module?

        Maybe in the case you mentioned, the devices are stateless and there is no harm to reinstall from scratch. My question is more generic:

        What is the mitigation approach to reuse the the content of a TPM-based encrypted disk when the motherboard is replaced?
        I don't know what the nominal / commended setup is so this may be orthogonal -- but regardless of TPM use / non-use I think that if the underlying FDE used LUKS then there may possibly be set up to be multiple equally capable alternative key slots for any given FDE / otherwise partition and that one may have administrative choice to install multiple equivalently useful keys into any number of those possible slots. So there could be multiple enrolled pass-phrase based keys, multiple enrolled FIDO2 key based keys, multiple "keyfile" based keys, and also possibly a TPM associated key in whatever mix in the possible key slots. Thus if one removed the storage device fom the computer and transplanted it to another then although TPM based unlocking may be impossible any other previously configured alternative / recovery key associated with the partition(s) could be supplied by the appropriate means to alternatively unlock that partition.
        q.v.
        man systemd-cryptenroll

        At least usually when a "user" supplies a password / key to something (not speaking specifically to this scenario but in general) there's typically an IT / sysadmin based "master key" alternative which can be used instead to get into the thing so that could be done as-above if it was desired to have the TPM not be the sole means of accessing the volume.

        What is supported by the current / envisioned ubuntu installers and what is supported by other possible (e.g. non LUKS) based FDE options which ubuntu might eventually support IDK.

        Then again for some kinds of devices the storage devices aren't practically physically removable from the machine -- e.g. laptops / etc. with soldered-in SSD storage chips, so in those cases if there was a TPM based mechanism defined and the TPM got corrupted then there would still perhaps be a way to recover the data if the machine could somehow be made to boot and ask for another defined unlock means (pass phrase, FIDO2 key, full key file, whatever). I vaguely recall hearing that it's possible to "brick" some kinds of devices by configuring a secured boot that just won't let it boot anything but the blessed image but then having that image or its stored keys become altered / corrupted if the system is without an option to reconfigure / override / recover. On the other hand with the right BIOS access / passwords etc. it may (most commonly) be possible to administratively reconfigure the TPM to allow something else to be booted (e.g. USB media) then use that to recover the main drive via alternative pass phrase / key file etc. assuming the stored encryption is intact but somehow the boot code changed or the TPM lost its key or something.


        Comment


        • #14
          AFAIK 23.04 supports LVM + ext4 based FDE from its installer, though one didn't have the choice (IIRC) to set up something else like ZFS + encryption, btrfs root + encryption, and even going with the encryption + ext4 option one could only use a pass phrase for the encryption and at that time neither TPM nor FIDO2 key configuration / use was supported by the installer / OS / initramfs with any kind of automation / facilitation I know of to set it up and have it work subsequently without some pain / risk.

          The linked article on 23.10 ZFS support says "For 23.10 ZFS encryption is not supported.".

          Is there any easy scenario (e.g. with 23.10 ubuntu or whatever is newish from OpenSUSE / Fedora / Debian) to just install / maintain ZFS root + storage with encryption or at least BTRFS root + storage with encryption even excepting TPM support but retaining whatever other expected options exist -- pass phrase, FIDO2 key, ...?

          And on another related but separate topic it occurs to me that it might be interesting / useful to have TPM support but not necessarily as an exclusive means to unlock a FDE volume.
          In the simplest case regardless of FDE involvement I could see it being interesting to even just authenticate the integrity of the BIOS settings and and boot loader / initramfs / kernel or whatever and say refuse to boot if the signatures didn't match. "FDE" could still be used (well at least for the non boot / initramfs parts of the OS root + storage) but that could rely on additional or separate means of unlocking -- pass phrase, key, et. al.

          Similarly I could envision some multi-tiered setup where one had to have a pass phrase or key in addition to a TPM based key for the TPM to permit the system to open the FDE / boot.

          Are those sorts of things possible wrt. TPM and what underlying LINUX boot / FDE / trusted updates & signing & TPE support SW supports even if not fully enabled now by
          the 23.10 installer, for instance?

          Comment


          • #15
            Originally posted by pong View Post
            AFAIK 23.04 supports LVM + ext4 based FDE from its installer, though one didn't have the choice (IIRC) to set up something else like ZFS + encryption, btrfs root + encryption, and even going with the encryption + ext4 option one could only use a pass phrase for the encryption and at that time neither TPM nor FIDO2 key configuration / use was supported by the installer / OS / initramfs with any kind of automation / facilitation I know of to set it up and have it work subsequently without some pain / risk.

            The linked article on 23.10 ZFS support says "For 23.10 ZFS encryption is not supported.".

            Is there any easy scenario (e.g. with 23.10 ubuntu or whatever is newish from OpenSUSE / Fedora / Debian) to just install / maintain ZFS root + storage with encryption or at least BTRFS root + storage with encryption even excepting TPM support but retaining whatever other expected options exist -- pass phrase, FIDO2 key, ...?

            And on another related but separate topic it occurs to me that it might be interesting / useful to have TPM support but not necessarily as an exclusive means to unlock a FDE volume.
            In the simplest case regardless of FDE involvement I could see it being interesting to even just authenticate the integrity of the BIOS settings and and boot loader / initramfs / kernel or whatever and say refuse to boot if the signatures didn't match. "FDE" could still be used (well at least for the non boot / initramfs parts of the OS root + storage) but that could rely on additional or separate means of unlocking -- pass phrase, key, et. al.

            Similarly I could envision some multi-tiered setup where one had to have a pass phrase or key in addition to a TPM based key for the TPM to permit the system to open the FDE / boot.

            Are those sorts of things possible wrt. TPM and what underlying LINUX boot / FDE / trusted updates & signing & TPE support SW supports even if not fully enabled now by
            the 23.10 installer, for instance?
            I think the Ubuntu blog post explains some of your questions more detailed:

            Comment


            • #16
              Originally posted by Mirox View Post

              When one of those Ubuntu devices has a motherboard issue. How would the admin switch to another machine having a different TPM module?

              Maybe in the case you mentioned, the devices are stateless and there is no harm to reinstall from scratch. My question is more generic:

              What is the mitigation approach to reuse the the content of a TPM-based encrypted disk when the motherboard is replaced?
              TLDR: LUKS has more then one key slot. There is a master key in a separate slot from the TPM and you need to use this key to unlock if the TPM isn't available for automatic unlocking. Then the key from the new TPM needs be added to the a key slot to re enable automatic unlocking again.

              One can use the multiple slots also to habe multiple disk unlock keys for different users.
              Last edited by slalomsk8er; 25 September 2023, 05:13 AM. Reason: fix typo

              Comment


              • #17
                Originally posted by slalomsk8er View Post
                TLDR: LUKS has more then one key slot. There is a master key in a separate slot from the TPM and you need to use this key to unlock if the TPM isn't available for automatic unlocking. Then the key from the new TPM needs be added to the a key slot to re enable automatic unlocking again.

                One can use the multiple slots also to habe multiple disk unlock keys for different users.
                LUKS slot keys are not master keys. They are encrypted forms of disk master key. It is also possible dump plain disk master key for recovery purpose.

                Comment


                • #18
                  Originally posted by botipua22 View Post
                  Today I suddenly noticed that I haven't seen any Phoronix articles in my feed reader for the past few weeks. It seems the entire Phoronix site is behind an aggressive Cloudflare firewall rule that's blocking access to /rss.php from my feed reader (NewsFlash on Fedora GNOME). I can't open Phoronix these days without going through the Cloudflare security check, which my browser can solve with JS but a feed reader like NewsFlash can't. Perhaps Michael can add an exception to /rss.php in Cloudflare?
                  Just to let you know, the Phoronix RSS feed still works for me, but I'm using the Livemarks Firefox plugin.

                  Comment


                  • #19
                    Originally posted by M@GOid View Post

                    Just to let you know, the Phoronix RSS feed still works for me, but I'm using the Livemarks Firefox plugin.
                    It's possible that the Cloudflare rule is country or region specific. I have seen some sites wholesale blocking/challenging all traffic from South Asian countries. I can understand the motive because the place is a known spam hotbed, but genuine users also end up getting affected.

                    Comment

                    Working...
                    X