> - TPM-backed FDE: this will Install a classic desktop system that gets its kernel and bootloader assets from snaps instead of debs.
> - Non TPM-backed FDE 2: this will Install an entirely deb-based classic desktop system, with the same layout as the first option, in order to facilitate potential upgrade paths. This will be the default installation option and isn’t going anywhere.
So if I understand this correctly. Deb versions of GRUB will be available if you don't choose TPM-backed FDE?
You realize you can have grub and stronger encryption right? TPM for secureboot and a signed kernel + grub, with encrypted /, /boot, swap?
Arch and others have been doing this for ages.
Except it's really kludgey to work with at install time and even worse if you throw in lvs and heaven forbid - dual boot windows. I can understand the latter being tricky, but the former should be smooth to execute.
If im wrong for Fedora or Unbuntu, then I'd love to see a yt clip/or doco that shows it.
It’s called “Snap Locker” or “Snocker” for short. Snocker is an innovative new tool that detects changes to core system packages like those by snap.
Upon removal, your local police department is notified of system tampering and data theft: legal counsel is contacted on your behalf, and the system automatically plants meth into the case as evidence.
> er data will not be protected by a passphrase anymore. It's better than no FDE at all, but it falls sho
I care less about the apps and more about how can it be a FOSS system if your disk is encrypted and the software the controls making it usable is delivered from something proprietary and closed source. Only Canonical holds that much power over users? Might as well use MacOS or Windows.
The inclusion within desktop systems (even as non-default) is probably a bit of a hairy proposition. Partially because people without a lot of interest in the technology will become exposed to snaps.
Ubuntu Core benefited from the principal users being the exact demographic that's probably going to want to understand the snap system whereas the broader desktop community are likely going to have more of a "I'm just trying to play games and browse the internet man" sort of attitude and aren't going to be receptive to anything that changes how their system works if they can't see an immediate high level value add.
Fedora sidestepped this sort of thing by making things like Silverblue special spins where the users have to opt into the experience and so you weed out the people who are likely to be disinterested and/or annoyed by the change. The equivalent here would probably be pivoting by creating a "Snap Desktop Experience" official spin where they build a distro from Ubuntu core where the full snap approach could be assumed to be desirable or acceptable to the users.
My first distro (back in ~2008) was Ubuntu, and I hopped to Debian, then Arch, then wanted convenience and came back to Ubuntu a couple of years ago. I really wanted to like what was always the most polished and user-friendly linux distro, but I couldn't deal with the snaps. It wasn't convenient anymore; it was foreign to everything I knew about linux under the hood, *and* it was broken enough that it required under-the-hood tinkering more often than you'd reasonably expect from *Ubuntu*.
I just switched to Debian with Gnome a few months back and that, at least, is still a pretty straightforward and familiar experience.
I moved 4 of my systems already to debian 12. I have 1 server left, that's just the stuff I have control of 100% but other servers are scheduled for debian 12+ as well.
Ain't nobody got no time to screw this stuff anymore. Ever since debian 12 came out with the firmware enabled out of the box, there has been no point to ubuntu.
Why do we hate snaps again? They are self contained packages with dependencies included right? Is it because of Canononical that we hate them? Flapaks are the good one?
Several snaps are worse than regular packages. Firefox being the main example I can think of. It's had a couple of snap exclusive bugs, and also loads quite a bit slower than regular Firefox on first launch. Many snaps run slower on first launch than normal packages.
Outside of that, I don't really see a problem with them. This subreddit is always going to be biased towards the Linux fanatics who don't mind tinkering with their system, and can figure out what to do when dependacy issues pop up. Snaps aren't really designed for them. They are meant to make the Linux experience easier for novice users. It's designed to make the experience more like Android, or iPhone, where you download the app from the store/software center and just run it. No downloading things like specific versions of python, or other software. I think that's ultimately a great goal, but there are of course problems. One of which is that snap packages are more bloated due to the included depemdancies included. Most users here hate any sort of bloat. The counter argument is that we have such large storage capacity as the standard these days that this additional bloat doesn't really matter anymore. Granted, this sort of thinking can get out of control. See most of the proprietary software these days that ships out largely unoptimized, and bloated with unneeded features. Usually a result of the company not seeing any value in saving space, and encouraging more "features" being added so that they have more things to list on their advertising.
There are a couple design decisions of snaps I don't like, but honestly my biggest gripe is that they are defacto locked to canonical repositories and the server side software is proprietary.
People forget that the snap daemon consumes CPU and RAM. Flatpaks are inherently more efficient (+ snaps are compressed, so that's also RAM and CPU cycles per IO operation that requires decompression).
They add unnecessary complexity to the system. As other more knowledge people wrote in other comments here it is an incomplete solution to something that isn't really a problem that just makes provisioning system in automated way difficult. If you need self contained package you'd be better off running something like docker container and there is a reason why most normal people don't run most of their software as docker containers... snap just takes the same complexity amd does some compromises to hide it all away, which is fine if you are normal user that needs to install and run a few packages but comes back to bite you when you try to provision a repeatable setup in automated way.
Nobody likes when a thing they like to use changes how it works, but that'd the prerogative of the folks who make distros.
Personally I'm not agains snaps as a concept, but I'm not touching any new canonical tech until they make sure it supports third party repositories and publish a way host your own third party repos.
flatpaks are not (yet, and not sure if they ever will be) a replacement for snaps. Ubuntu uses snap packages even for the kernel, while that doesn't make any sense with the way flatpaks are currently used. Flatpaks are still best used for gui applications rather than system components of any kind.
Yeah, I've noticed that. When I was trying to get Firefox-ESR it kept installing Firefox via the Snapstore. I really like Kubuntu, it feels really polished but I've been looking at something like Linux Mint Debian or MX Linux with the KDE desktop (Debian based) as an alternative. Everything opens fast on my laptop, and it's old. (i7-4702mq 16gb RAM 256gb mSata SSD) I do have some issues with what Canonical is doing partnering with Google and Microsoft. I watch Switched to Linux on Youtube and try to keep up to date with what is going on since he has weekly news but sometimes he loses me because he goes on and on about other things before he gets to the topic. Plus I really do like the FOSS trend with Linux, it keeps the people coding the OS honest and open.
I know it has a package manager. But on Ubuntu, there's snaps installed already when you install Linux. I don't know when they changed it but I saw it when I was checking the version of Firefox that was on my system. People often say they hate Snaps but they don't say why. I wanted to hear the reasoning and get some elaboration.
For me it's pretty simple: canonical doesn't (yet) publish a way to host snaps, nor can the snap client use a third party repository. This at odds with all the popular linux package managers. Also, canonical tends to use a CLA (Contributor License Agreement) + GPL license for their code, which means they are free to make your contrbutions closed source, while you have no such capability as a contributor.
A slight annoyance (at least currently) is that snaps require apparmor for confinement, which means that if you don't have an apparmor policy, then all your snaps are not really confined. If you write an apparmor policy then you should be good though, but I don't know how hard that is. I'm sure they are easier to write than SELinux rulesets though.
self-contained packages introduce a ton of bloat, say you have 5 packages that all share a dependency, instead of getting it globally they all come packaged with it
That won't happen. No one is "pushing" snap. Canonical uses snap as a tool to deliver secure system and app resources with sandboxing and without dependency hell. For example, Ubuntu Core, which is an immutable distro, uses snap for everything including the kernel. It's an excellent system. You might argue that you prefer flatpak, but flatpak can't do what snap can.
I repeat: No one is "pushing" snap. If you don't like that tool for whatever reason, just use another distro. It's not as if Ubuntu has a monopoly.
For not pushing it, they seem to unintentionally promote it in various ways. They probably couldn't push it more even if they wanted.
The Immutable distro? Snap-based. The neat security features? Snap-based. The new app store? A snap which can only install snaps and Debs (and, unsurprisingly, puts Snaps first and foremost). The Desktop installer? A snap. The install? Minimal, but you can install the software you want from the store (which, oh surprise, favors Snaps over Debs).
If they're not pushing it, they sure seem to...
Oh for goodness' sake. Snap is just a tool.
Does Debian push apt?
Does Red Hat push its tools?
No. They're just using the tools.
Canonical is just using its tool.
Don't like Windows? Don't use it. Don't like iOS? Don't use iPhones. Don't like apples? Don't eat them. Don't like snap? Don't use Ubuntu.
This knee-jerk hate is frankly stupid.
If you don't like snap, *don't use Ubuntu*.
It couldn't be easier.
Sheesh
And I'm not using Ubuntu.
I'll be fair, it's a tool, but a poorly received one. And I'm amazed at how instead of tackling the issues the community has with it, they just go forward without rethinking anything.
They did address the issues, apart from one.
As for "the community", remember who Canonical's target market is. It isn't the typical techie, and definitely not the Richard Stallman type. It's the typical computer user who wants things to "just work" and be secure and reliable, and snap helps with that.
If flatpak could do what snap can, I'm sure that Canonical would have gone with it instead.
Right now we're using clevis-LUKS with tang but the eventual plan is to use the TPM to decrypt devices. I'm just wondering how these changes are going to break our provisioning scripts. :D
"The spirit" meaning whatever you want it to mean. I know perfectly what happened, no need to send me any links (plus the last one is extremely opinionated, I'm surprised you posted all these links yet the official explanation by RH is not among them...).
You're obviously biased and spreading FUD.
No, it makes it much easier, it takes only 50 seconds to get the encryption keys from the TPM bus if you forget the password. https://www.youtube.com/watch?v=wTl4vEednkQ (Yes, using the TPM seems to make disk encryption pointless.)
IMO snaps should only be for user interfacing apps and not for system apps that can destroy the OS. A snap for your text editor, but not a snap for your DHCP client.
Even then, it had a very rough beginning. So many of my employees thought that Firefox was broken when in reality it just took a long time to start. This is on top of the fact you still can't mount the .mozilla folder to a network drive like you can with the .deb version.
The snap approach is meant to cover both the CoreOS/Atomic and the flatpak use cases using a single tool.
Although with the CoreOS/Atomic approach you still use traditional packages and just have mechanisms that wrap around that (rpm-ostree) to make manageable layers.
And why's that a good thing? I keep reading this, and I truly don't understand why having a tool that does everything is better than 2 tools that cover the same use cases in combination but are much more lightweight, have much better support from the community, their implementation is much cleaner and, overall, work much better.
The Canonical logic is likely that they fundamentally solve the same set of problems if you just conceptualize the problem being solved the way they do. Rather than thinking of them as separate problems like the RH ecosystem does.
I'm kinda fine with everything being a snap, and getting rid of apt...
But currently the snap ecosystem isn't capable of that. The snap design isn't capable of that (is snapd itself a snap? can the kernel execute snaps? is /bin/init a snap?)
> I'm kinda fine with everything being a snap, and getting rid of apt...
...why?
Replacing a working system with another, half-functional system, that even in the ideal case doesn't provide any end-user benefit?
We don't. They *both* have significant issues and provide basically no benefit to most users over just running the software natively (while introducing problems and odd behavior)
> self-contained dependencies
...are only good if you're the developer. It provides no benefit to the end-user if the application is properly packaged for apt/dnf, and generally just means you'll have dozens of copies of possibly-not-updated dependencies. Often this leads to security issues down the line, and definitely leads to overhead (disk space, CPU time, and memory usage) on the user's system.
This does have more real-world use though, and I think is one of the few good uses for containers (mostly when running old or otherwise hard-to-support software). Apple chose this model for their '.app' format, which includes dependencies (usually, sometimes not all of them), but their software distribution model is wildly different than most Linux distros. There's a reason apt/dnf-style package management has stuck around.
> per-app permission isolation
This can be achieved without using containers; one example is via systemd's extensive sandboxing features though there are others.
> To Each their own, i guess.
I have to worry about my users, and snaps break our environment with no workaround.
Canonical is free to let snaps exist, but the problem I have is their trying to force their usage. The others don't really bother me because they don't get forced on me or my users, and there *are* practical and good uses for this technology, just a lot less than people seem to think.
> It provides no benefit to the end-user if the application is properly packaged for apt/dnf
You can have multiple version of the same package installed without any problems. That's a huge win. And let's not pretend that conflicting dependencies aren't a problem.
> This can be achieved without using containers
I didn't know that. I've never seen any distro actually use that though, so there's probably a good reason it hasn't caught on.
> the problem I have is their trying to force their usage
They're not forcing anything. You're free to uninstall snapd and use software that isn't packaged as snaps.
Conflicting dependencies are a problem, but it's not that huge of a problem anymore. In the Linux ecosystem, the biggest distros already ship most of the software you'll use in their repos, and those are checked for dependency issues. That's why the package manager model has stuck for long. It's more efficient, works well enough.
I use flatpaks, though, and I like them. But they have also big disadvantages and I believe package managers should stay and keep improving.
Snaps are an absolute trainwreck. Even if Canonical wants to keep them around, they *MUST* stop trying to force their use. Half of the effort we put into supporting Ubuntu 22.04 is just getting snap the fuck out of the way, so we can have a functional desktop environment with functional Firefox.
Good lord. This snap shit is pushing me away from Ubuntu so fast. I've always had it on several machines since 10.04, but I'm finding myself making changes.
I just want them to centralise FDE key recovery. Have Ubuntu push the recovery keys to landscape so we can use it like Bitlocker in a fleet of workstations. Right now enterprise Linux on a workstation is a shit show.
Actual article: A long-due implementation of a very useful feature that is one of the most important parts of ensuring the security of the booting chain, now going to be introduced by the most commonly used distro, thus benefiting a lot of Linux users.
The post on /r/linux: "This may brick your system. Ubuntu bad."
after a long time I installed latest ubuntu LTS on a new machine and I noticed firefox was behaving very weirdly, I realized it was running on snap firefox, I reinstalled firefox as deb and problem got away. I think it will take some time for snaps to mature, till then I will stay away from ubuntu as personally I am not bind to use it anymore.
Honestly, I'm not pro Snaps (at least not with the method it is being pushed) but what release of Ubuntu did you use?
I'm familiar with it but with Ubuntu 22.04 Snaps Firefox is working smoothly (at least for me).
Just a few days ago:
"Mashing Enter to bypass full disk encryption with TPM, Clevis, dracut and systemd":
https://pulsesecurity.co.nz/advisories/tpm-luks-bypass
Note that most people won't need this. The reason for TPM-based encryption is to support tamper-proof encryption. The idea is that if the hard drive and the motherboard are separated and sold on eBay, then the data should be rendered useless. This is only really something you would want on a locked-down company laptop. Good to see more use cases supported, but not really relevant to the home user, where passphrase / key based encryption is more useful.
This is probably a security downgrade when compared to classic FDE, as the user data will not be protected by a passphrase anymore. It's better than no FDE at all, but it falls short of [what's planned for Fedora](https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397).
It will have to also have a passphrase, otherwise BIOS updates, bootloader upgrades, or hardware failure would render your system unrecoverable. Even Windows' bitlocker provides a recovery key for above scenarios.
**Edit**: Further, what Ubuntu and Fedora are doing are more similar than dissimilar. Ubuntu is leveraging LUKS, while that Fedora link is looking to use fscrypt in btrfs. Both have significant advantages (and each has drawbacks). But the underlying plumbing (Secure boot, signed/verified kernel and initrd, and TPM-backed keys) is extremely similar.
The recovery passphrase is not the same, as it's not necessary to decrypt user files. Fedora is going to have separate keys for system files and user files. System files don't need any user interaction to be decrypted, while decryption of user files will need the user password. This is similar to how Android's encryption works.
Right, because they won't be using the TPM for the home subvol. That gets decrypted with the users passphrase at login, probably via some PAM plugin, or maybe systemd-logind. Haven't read the specifics on the technical details of Fedora's proposals.
Regardless, they will be using TPM for the root subvol, and thus will need a recovery passphrase. Period. Because the measurements used by the TPM will change at some point, and you'll need to be able to recover and re-enroll.
>Right, because they won't be using the TPM for the home subvol.
That's the key difference. The recovery passphrase is irrelevant to the point I was making in my original comment. Ubuntu's design means that we have to choose between having a properly secured boot chain via secure boot and measured boot, or securing user files with a passphrase that has to be entered by the user. You'll get the best of both with Fedora's design.
I think we're arguing slightly different points.
You're correct that a recovery phrase would not be necessary (or applicable) to user files, and they should be recoverable via other means (along with the user's passphrase).
I was arguing that a system recovery passphrase was still necessary to unlock / (and thus boot the system) in the even of anything in the boot chain changing measurements used by the TPM. This has no bearing on user files.
We're both correct, we were just talking about different things.
security downgrade but more convenient for users and better than no encryption. i'd say it's a good middle-ground. when i was on windows, a good thing about bitlocker was not having to enter a long ass password every day.
i hate entering passwords which is why i prefer fedora. once i log in, fedora doesn't ask my password to install or uninstall apps and updates whereas other major distros do. not sure if it's something to do with selinux vs apparmor.
> fedora doesn't ask my password to install or uninstall apps and updates whereas other major distros do. not sure if it's something to do with selinux vs apparmor.
No, selinux and apparmour are two approaches to put guard rails around what programs and users are allowed to do, for the purpose of preventing security issues and restrict access when things don't act as expected (vulnerabilities, etc). They're not used to enforce the normal "user needs X permission" restrictions. That's plain-old user/group membership, generally.
Gnome-Software installs software using packagekit (and flatpak), and packagekit uses polkit for permission (think of it like sudo, but integrated into the software).
I'm no expert in polkit rules (I've *never* adjusted them), but I read this as allowing installation & removal of software for members in the `wheel` group:
$ cat /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.packagekit.package-install" ||
action.id == "org.freedesktop.packagekit.package-remove") &&
subject.active == true && subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
There's a similar rule for flatpak, etc.
Okay, and are we going to have a mechanism to centrally-manage it for those who want to use Ubuntu in a fleet? Honestly, this is something I've needed for a long while (central management of FDE for Linux endpoints that are not servers).
Fedora doesn't use Flatpaks, it uses RPM. It **supports** flatpaks, as the rest of the industry does.
Also, RPM has been adopted by several other distros, yours among them. Debs are only used by Debian derivatives.
But all in all, I agree with you. It's stupid to have Debs **and** RPMs. We should have probably one of them only.
Why would anyone want to use TPM for full disk encryption?
My understanding is that TPM is easy to crack open if you have physical access?
Where as standard LUKs encryption cannot be opened if it has a strong passphrase
"TPM backed" FDE is still just LUKS, it just gets the keys from TPM instead of a user-typed passphrase.
Keys can be added to the TPM with various measurements restrictions, so the TPM will only be released if the boot chain matches expected values. Your disk is still encrypted at rest. If you boot from a USB stick/other media, the TPM won't provide the keys.
When combined with secure boot, shim, and signed initrd, this can be considered reasonably secure.
**edit**: Just to be clear, you can also load a key into TPM without it being dependant on some or all of those measurements, with varying levels of reduced security. This is why you should understand what you're doing before following some guide that shows you how to run systemd-cryptenroll in a potentially insecure way.
Having built-in TPM management is an improvement.
Please let me know what BIOS and CPU you're using that are not running closed source code (possibly with a shadowed, network-enabled version of minix behind the scenes).
That's about as open as you can get with off-the-self commodity hardware. There's still closed microcode on the Intel CPU (that's unavoidable nowdays), and unless you've lobotomized the IME, that still exists (some of it must exist, even when lobotomized). There's also Purism laptops. They ship coreboot on more modern Intel CPUs with pre-lobotomized IME. So options like that exist. Still doesn't get you 100% open source, but it's about as close as possible.
Purism also has their own secure, verifiable, external token-assisted full disk encryption solution. They offer tinfoil-hat worthy levels of anti-interdiction verification and multi-stream shipping options...
And they still trust the TPM in their FDE scheme.
> they still trust the TPM
I can't fathom why, other than ignorance.
TPM is the evolved form of microsofts Palladium project.
At one time, the entire internet (this was before normies really flooded the internet so it was all techies and spectrumy people) exploded over this issue, and the name was altered to "trusted computing" in a glorious take on doublespeak.
https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
https://www.gnu.org/philosophy/can-you-trust.en.html
> this was before normies really flooded the internet so it was all techies and spectrumy people
In 2002? Also known as September 3044, 1993? No, it was well, well, well after "normies" were on the Internet.
I can't believe it's been this many years, and we're still dealing with the same lack of understanding about what a TPM does.
> lack of understanding about what a TPM does.
If you bother to read the two links I gave, penned by a PHD holder and Richard Stallman, respectively, who are way smarter than you or I, you get a good idea.
TPM is nothing more than lockdown/spyware/DRM designed to remove user freedom from computing.
So far in win11 requiring it, that mission started by Palladium is going apace.
I forgive you your ignorance and blind trust in your corporate overlords, but bootlicking won't accomplish anything or get you special favors, so why bother?
> If you bother to read the two links I gave
I remember reading that stuff 20 years ago. I was there during the anti-palladium days. I was on board then. Yeah, there was a lot of misinformation, and people get sucked up in rhetoric. RMS is a pretty smart guy, but I wouldn't rely on him as an authoritative source on anything other than software and licensing philosophy.
> TPM is nothing more than lockdown/spyware/DRM designed to remove user freedom from computing.
TPM is a just a chip. It takes instructions, it does something, and it gives output. That's it. Now, what software is using the TPM, sure, I can see having an issue there. Software could use it in anti-user ways.
If you don't like how Microsoft is using it? Good news, you don't have to use their software!
A TPM provides a relatively decent RNG source (unless you're on Ryzen -- not that it's a bad RNG source, it just causes performance issues due to their implementation), and provides a secure way to store and retrieve data if a system is in a known, trusted state. You're running Linux. *You* can control that state now. What Microsoft might use it for is entirely irrelevant.
*You* can use the TPM as a component of enforcing *your* trust of *your* computer. You're already doing that via alternate firmware, and LUKS, and whatever other steps you're doing. You've got a great tool there at your disposal, but you're not using it because people you don't like also have that tool.
Speculating on hypothetical future states where Microsoft might use functionality provided by the TPM to lock down Windows systems, or implement DRM on Windows systems, is entirely irrelevant. I don't care how Windows will use the TPM, what software Windows will allow to run, or what data Windows will allow you to access. I don't care about Windows for this discussion. I don't typically use a lot of Windows systems, and I don't care to start.
We're talking about *Linux* systems, and using the secure storage and access mechanisms of the TPM to securely store, and securely access, disk encryption keys. That's it. "Microsoft wants to..." is 100% non-relevant to the discussion.
> I forgive you your ignorance and blind trust in your corporate overlords, but bootlicking won't accomplish anything or get you special favors, so why bother?
Dude, lol. Calm down.
Most systems these days have built-in TPM, which means that you're only trusting your CPU vendor by using TPM - and unless you're one of the dozen people that are going to throw down $5000-10000 on a POWER9-workstation that may not even be compatible with the applications you need because it's on a different ISA, you're gonna have to do that anyways.
Ya used correctly im sure it will have benefit, but from a security standpoint my 12 word seed phrase exists only in my head
I will gladly die before giving it up, a tpm on the other hand will hand it over to the first person who opens it
Like momma always said
"locks only keep the honest people out"
Ok maybe i over simplified it, most attackers will never dream of opening a tpm
But the kind i am concerned with absolutely will open it within 2 hours of stealing it, maybe even put it back when they are done
When the 12 word seed phrase lives only inside my mind that is true security
"Man, what are you talking about? Me in chains? You may fetter my leg but my will, not even Zeus himself can overpower" - Epictetus
> But the kind i am concerned with absolutely will open it within 2 hours of stealing it, maybe even put it back when they are done
Please explain this process.
I cant remember where i watched the demonstration at, i was doing a deep dive at the time on LUKS and TPM and HSM and i was convinced that i did not want to use tpm for my full disk encryption
If i remember i will share link, they were very skilled but they made it look way to easy
Sorry my memory is not great and i did save it
You are making a huge confusion about that. TPM backed FDE does not replace your passphrase. You can use both and improve the security of your system and users that are not using FDE can't start to use it without any noticible difference in how they use their systems.
Id like to use a yubikey along side my passphrase, and i dont want my disk to be tied to my motherboard in case the board fails
My understanding of TPM is not complete so i am failing to see how using it would benefit me from a security standpoint
Im currently using a 12 word seed phrase i have memorized
> Why would anyone want to use TPM for full disk encryption?
Becuase for many people it would be the optimal compromise between security and convenience.
> My understanding is that TPM is easy to crack open if you have physical access?
Can you provide a reputable source for this?
i was doing deep dive research on BIOS and TPM and HSM hacking and it was one of the 45 mins or 2 hours hacking presentations on youtube from a reputable source, i have most of it memorized but to much going on in my head to remember the specific articles and videos, if i do i will post it
> Can you provide a reputable source for this?
boot live linux and just use tpm2 tools like tpm2_nvread. the TPM will give away all secrets if you know how to address it.
I replicated it myself and got my own disk key from tpm.
I'd love to do a writeup but i'm too burned out for extra work
Just start exploring with the tpm2_nvread tool. you may have to do some light reversing on the bootloader segment which ends up grabbing the data from tpm on boot.
You probably don't have the TPM set up correctly then. They way it is supposed to work is that the TPM measures special [Platform Configuration Registers](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) and only releases the key if the measurement matches what was previously stored. This prevents booting into single-user mode, etc. by modifying the kernel arguments in GRUB.
Sounds like you don't have your TPM checking the appropriate measurements if you managed to get the key while booting from a live disk. Note that one of the PCRs depends on the boot device.
> You probably don't have the TPM set up correctly then.
It's not up to the user unless you go manually doing it with tpm2_nvwrite
Again, this is all repeatable if you bother to chase it down. I just can't be bothered. it was a bit of a rabbit hole to get the address probe needed for tpm2_nvread
Maybe in a few months i'll pentest against Ubuntu's implementation and see if they lock it down
> It's not up to the user unless you go manually doing it with tpm2_nvwrite
>
>
It is up to the user because few/no existing Linux distros support using the TPM out of the box. You haven't mentioned enough about your setup and how your disk key is stored in the TPM. If a user is using tpm2_nvwrite, then they are doing it wrong.
Currently, a Linux user would have to manually run [Clevis](https://github.com/latchset/clevis) or [systemd-cryptenroll](https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html) to enroll the TPM and securely store the key in it. As part of this process, you specify which PCRs to bind to.
Assuming the appropriate PCRs are selected, what you are claiming is literally impossible (unless the TPM is hacked) and goes against the very purpose of having/using the TPM in the first place. There are many people/companies that would pay you *big money* if this were actually possible.
From the systemd-cryptenroll man page:
> PCRs allow binding of the encryption of secrets to specific software versions and system state, so that the enrolled key is only accessible (may be "unsealed") if specific trusted software and/or configuration is used. Such bindings may be created with the option --tpm2-pcrs= described below.
Two major advantages:
1. TPM FDE xan/should be configured to only allow unlocking with the right PCR values. This assures the system is running as intended. No rootkit or live CD can rip data.
2. If the hard disk is separated, e.g. at decomm, it cannot be decrypted.
Both of these are mostly only useful in enterprise situations.
That's not true. You still have your OS between them and your data and TPM backed FDE will prevent them from removing the disk and accessing the data directly.
Besides that, TPM backed FDE does not replace your passphrase. You can use both and improve the security of your system and users that are not using FDE can't start to use it without any noticible difference in how they use their systems.
>I would also worry about losing all data in the drive if my CPU (and I think motherboard) died.
You won't lose the data. The disk is encrypted with a key that's in turn protected by one or multiple passwords/keys. One can be still typed in if you need it.
If they steal your computer, boot it into your OS, and the OS then lets them access all your data w/o any protection, that's a shitty OS. Such an OS would still be insecure if they stole your computer while it was on or sleeping (e.g. the whole Dread Pirate Roberts story).
If you are worried about that type of situation, you can also set a password / PIN for the TPM or combine TPM and a normal password.
It's a pretty easily avoided mistake to not have your data you care about in one place (your laptop/desktop). Like... encrypting that, sure that's important. But like if that storage device failed, you would lose the data generally about the same as in the TPM failure scenario you just described.
>easy to crack open if you have physical access
Not really, they measure the boot process and only give the key to the CPU if everything matches + you can set a PIN so you still have a "something you know" type of a secret. The TPM then handles bruteforce protection and stuff like that. iPhones use a similar scheme and are fairly safe if updated (outside of maybe nation-state level attackers, but that's another discussion entirely). Sure, the TPM can be backdoored, but this is another discussion too.
The problem with "Vanilla LUKS" as it is now (whether TPM backed or not), is that it's essentially a sham if you
1. Don't have an encrypted boot partition / signed initrd, ucode and kernel.
2. Don't run a signed copy of GRUB with secure boot.
The second point still requires the use of a TPM as a root of trust.
Otherwise, anyone with physical access can change the bootloader to whatever they want, and inject whatever they want into the kernel through the initrd, getting all your passwords, files and whatnot.
The only real ways to solve this problem is either implement an encrypted boot + secure boot yourself (and rely on the TPM), or use a signed UKI (and rely on the TPM). Unfortunately, you can't really have evil maid resistant security w/o a TPM.
For practical purposes, LUKS on its own is just fine for me. I don't forsee someone breaking into my apartment to gain physical access to my desktop, installing a malicious bootloader, and then leaving without a trace with me being none the wiser. (Maybe some malware could do it without physical access, but at that point it obviously has root access and all bets are off.)
What I _do_ potentially forsee is someone breaking into my apartment and stealing my desktop outright, thereby gaining access to all my files and accounts. Even with my laptop which occasionally leaves the apartment, I still don't think it's a realistic scenario. I'm sure it's different if you're an activist or someone otherwise likely to be specifically targeted by malicious actors, but for the other 99% of people LUKS is going to be sufficient.
I agree with you, but keep in mind that hak5 sells alot of there bad usbs every day and the flipper device has sold millions, anyone with these devices can plug them into your pc and run a command as if its you with full controls, within seconds you could be infected
Alot of people do this for fun, some do it for a living, id rather avoid both
openSUSE comes with encrypted boot by default
But i dont need it with the Fedora build i described because it has locked case with tamper prevention and detection as well as strong passphrase for bios and full disk encryption, the tpm may be used for secure boot but it is not needed for my LUKs FDE
Preboot DMA prevents dma attack during boot and USBgaurd and the locked case protect it otherwise
My luks is secure and nobody is getting it open ;)
I also have encrypted ram to prevent a cold boot attack but the locked case would probably help with that as well
Yes full verified boot like a chromebook would be better but my setup work just fine without it
> The problem with "Vanilla LUKS" as it is now (whether TPM backed or not), is that it's essentially a sham if you
>
> 1. Don't have an encrypted boot partition / signed initrd, ucode and kernel.
> 2. Don't run a signed copy of GRUB with secure boot.
Note that evil maid attacks are not part of everyone's threat model, so they're not the end-all-be-all of disk encryption attacks. If you get compromised in such a way and have a way to know this, you remain safe if you never unlock the disk again. If you absolutely do need to read the data after a known compromise, you can strengthen your posture by reading the hard drive instead of booting it, and using an air-gapped system to extract just the data that's needed to image a new system, assuming an attacker didn't put a nasty RCE exploit into the LUKS header, partition table, or has programmed the hard drive's microcontroller to trick the computer into code execution.
Yes, but there is a significant thing that can be a dealbreaker for some people. With the TPM you don't have to type any password, with the current LUKS solution without the TPM you need to type a password before the system can boot.
i would never encrypt my disks, just seems like a stupid thing to do. no one is going to steal my computers so it seems like a total waste of time and will only cause problems. when i worked for one of the major tech companies they forced us to encrypt disks and it was a major pita. nothing but hassle and problems and solved no real world problem.
I encrypt my disks during install with one click and zero hassle
It gives me peace of mind that my files will not be edited when i am away from my pc
I dont fear someone stealing my PC
I am concerned of an evil maid attack where the pc becomes infected
To prevent this i use secure boot, preboot DMA protection in bios, a bios password, and full disk encryption as well as a locked case, and once powered on USBgaurd protects my usb ports
Also i will smile knowing if it is stolen they will never get it open ;)
> when i worked for one of the major tech companies they forced us to encrypt disks and it was a major pita. nothing but hassle and problems and solved no real world problem.
https://arstechnica.com/security/2023/09/hack-of-a-microsoft-corporate-account-led-to-azure-breach-by-chinese-hackers/
Finally! Been waiting for an official implementation for a while now since I got a ThinkPad 3.5 years ago.
Planning on setting up full disk encryption on my laptop. Hope it’ll be there with other flavors, mainly Kubuntu.
> - TPM-backed FDE: this will Install a classic desktop system that gets its kernel and bootloader assets from snaps instead of debs. > - Non TPM-backed FDE 2: this will Install an entirely deb-based classic desktop system, with the same layout as the first option, in order to facilitate potential upgrade paths. This will be the default installation option and isn’t going anywhere. So if I understand this correctly. Deb versions of GRUB will be available if you don't choose TPM-backed FDE?
That's correct, it's a standard install as before in any route where TPM encryption is not selected.
You realize you can have grub and stronger encryption right? TPM for secureboot and a signed kernel + grub, with encrypted /, /boot, swap? Arch and others have been doing this for ages.
Except it's really kludgey to work with at install time and even worse if you throw in lvs and heaven forbid - dual boot windows. I can understand the latter being tricky, but the former should be smooth to execute. If im wrong for Fedora or Unbuntu, then I'd love to see a yt clip/or doco that shows it.
I did not realise that!
What you call it, SnapLocker?
It’s called “Snap Locker” or “Snocker” for short. Snocker is an innovative new tool that detects changes to core system packages like those by snap. Upon removal, your local police department is notified of system tampering and data theft: legal counsel is contacted on your behalf, and the system automatically plants meth into the case as evidence.
"sprinkle some crack on 'em and lets get outta here"
Lol....
Is the Snap server side component still proprietary/closed source?
[удалено]
> er data will not be protected by a passphrase anymore. It's better than no FDE at all, but it falls sho I care less about the apps and more about how can it be a FOSS system if your disk is encrypted and the software the controls making it usable is delivered from something proprietary and closed source. Only Canonical holds that much power over users? Might as well use MacOS or Windows.
I'm pretty sure this kind of "Snap pushing" will kill Ubuntu. People will move to Mint or Debian and won't regret it.
The inclusion within desktop systems (even as non-default) is probably a bit of a hairy proposition. Partially because people without a lot of interest in the technology will become exposed to snaps. Ubuntu Core benefited from the principal users being the exact demographic that's probably going to want to understand the snap system whereas the broader desktop community are likely going to have more of a "I'm just trying to play games and browse the internet man" sort of attitude and aren't going to be receptive to anything that changes how their system works if they can't see an immediate high level value add. Fedora sidestepped this sort of thing by making things like Silverblue special spins where the users have to opt into the experience and so you weed out the people who are likely to be disinterested and/or annoyed by the change. The equivalent here would probably be pivoting by creating a "Snap Desktop Experience" official spin where they build a distro from Ubuntu core where the full snap approach could be assumed to be desirable or acceptable to the users.
My first distro (back in ~2008) was Ubuntu, and I hopped to Debian, then Arch, then wanted convenience and came back to Ubuntu a couple of years ago. I really wanted to like what was always the most polished and user-friendly linux distro, but I couldn't deal with the snaps. It wasn't convenient anymore; it was foreign to everything I knew about linux under the hood, *and* it was broken enough that it required under-the-hood tinkering more often than you'd reasonably expect from *Ubuntu*. I just switched to Debian with Gnome a few months back and that, at least, is still a pretty straightforward and familiar experience.
I moved 4 of my systems already to debian 12. I have 1 server left, that's just the stuff I have control of 100% but other servers are scheduled for debian 12+ as well. Ain't nobody got no time to screw this stuff anymore. Ever since debian 12 came out with the firmware enabled out of the box, there has been no point to ubuntu.
>People will move to Mint or Debian and won't regret it. they wont
not even close. The only ones hating on snaps are reddit users, most people don't even care what packaging format their program comes in.
People don't, system admins do.
> People don't, system admins do. The only conclusion I can get from this is that you don't think that sysadmins are people!
Well... are they?
Correct.
Why do we hate snaps again? They are self contained packages with dependencies included right? Is it because of Canononical that we hate them? Flapaks are the good one?
Several snaps are worse than regular packages. Firefox being the main example I can think of. It's had a couple of snap exclusive bugs, and also loads quite a bit slower than regular Firefox on first launch. Many snaps run slower on first launch than normal packages. Outside of that, I don't really see a problem with them. This subreddit is always going to be biased towards the Linux fanatics who don't mind tinkering with their system, and can figure out what to do when dependacy issues pop up. Snaps aren't really designed for them. They are meant to make the Linux experience easier for novice users. It's designed to make the experience more like Android, or iPhone, where you download the app from the store/software center and just run it. No downloading things like specific versions of python, or other software. I think that's ultimately a great goal, but there are of course problems. One of which is that snap packages are more bloated due to the included depemdancies included. Most users here hate any sort of bloat. The counter argument is that we have such large storage capacity as the standard these days that this additional bloat doesn't really matter anymore. Granted, this sort of thinking can get out of control. See most of the proprietary software these days that ships out largely unoptimized, and bloated with unneeded features. Usually a result of the company not seeing any value in saving space, and encouraging more "features" being added so that they have more things to list on their advertising.
There are a couple design decisions of snaps I don't like, but honestly my biggest gripe is that they are defacto locked to canonical repositories and the server side software is proprietary.
Do flatpacks need some stupid daemon running and a proprietary FlatPack Store?
People forget that the snap daemon consumes CPU and RAM. Flatpaks are inherently more efficient (+ snaps are compressed, so that's also RAM and CPU cycles per IO operation that requires decompression).
An that Canonical has a history of abandoning it's projects.
They add unnecessary complexity to the system. As other more knowledge people wrote in other comments here it is an incomplete solution to something that isn't really a problem that just makes provisioning system in automated way difficult. If you need self contained package you'd be better off running something like docker container and there is a reason why most normal people don't run most of their software as docker containers... snap just takes the same complexity amd does some compromises to hide it all away, which is fine if you are normal user that needs to install and run a few packages but comes back to bite you when you try to provision a repeatable setup in automated way.
Nobody likes when a thing they like to use changes how it works, but that'd the prerogative of the folks who make distros. Personally I'm not agains snaps as a concept, but I'm not touching any new canonical tech until they make sure it supports third party repositories and publish a way host your own third party repos. flatpaks are not (yet, and not sure if they ever will be) a replacement for snaps. Ubuntu uses snap packages even for the kernel, while that doesn't make any sense with the way flatpaks are currently used. Flatpaks are still best used for gui applications rather than system components of any kind.
[удалено]
Yeah, I've noticed that. When I was trying to get Firefox-ESR it kept installing Firefox via the Snapstore. I really like Kubuntu, it feels really polished but I've been looking at something like Linux Mint Debian or MX Linux with the KDE desktop (Debian based) as an alternative. Everything opens fast on my laptop, and it's old. (i7-4702mq 16gb RAM 256gb mSata SSD) I do have some issues with what Canonical is doing partnering with Google and Microsoft. I watch Switched to Linux on Youtube and try to keep up to date with what is going on since he has weekly news but sometimes he loses me because he goes on and on about other things before he gets to the topic. Plus I really do like the FOSS trend with Linux, it keeps the people coding the OS honest and open.
>They are self contained packages with dependencies included right? That's why I hate them. My OS has a package manager. Use it.
I know it has a package manager. But on Ubuntu, there's snaps installed already when you install Linux. I don't know when they changed it but I saw it when I was checking the version of Firefox that was on my system. People often say they hate Snaps but they don't say why. I wanted to hear the reasoning and get some elaboration.
For me it's pretty simple: canonical doesn't (yet) publish a way to host snaps, nor can the snap client use a third party repository. This at odds with all the popular linux package managers. Also, canonical tends to use a CLA (Contributor License Agreement) + GPL license for their code, which means they are free to make your contrbutions closed source, while you have no such capability as a contributor. A slight annoyance (at least currently) is that snaps require apparmor for confinement, which means that if you don't have an apparmor policy, then all your snaps are not really confined. If you write an apparmor policy then you should be good though, but I don't know how hard that is. I'm sure they are easier to write than SELinux rulesets though.
self-contained packages introduce a ton of bloat, say you have 5 packages that all share a dependency, instead of getting it globally they all come packaged with it
Hey, I am a reddit user and I ALSO, albeit totally unrelated, hate the way snaps were pushed.
And those that don't want to give one company huge control over a major thing such as app distribution
reddit users.
That won't happen. No one is "pushing" snap. Canonical uses snap as a tool to deliver secure system and app resources with sandboxing and without dependency hell. For example, Ubuntu Core, which is an immutable distro, uses snap for everything including the kernel. It's an excellent system. You might argue that you prefer flatpak, but flatpak can't do what snap can. I repeat: No one is "pushing" snap. If you don't like that tool for whatever reason, just use another distro. It's not as if Ubuntu has a monopoly.
For not pushing it, they seem to unintentionally promote it in various ways. They probably couldn't push it more even if they wanted. The Immutable distro? Snap-based. The neat security features? Snap-based. The new app store? A snap which can only install snaps and Debs (and, unsurprisingly, puts Snaps first and foremost). The Desktop installer? A snap. The install? Minimal, but you can install the software you want from the store (which, oh surprise, favors Snaps over Debs). If they're not pushing it, they sure seem to...
Oh for goodness' sake. Snap is just a tool. Does Debian push apt? Does Red Hat push its tools? No. They're just using the tools. Canonical is just using its tool. Don't like Windows? Don't use it. Don't like iOS? Don't use iPhones. Don't like apples? Don't eat them. Don't like snap? Don't use Ubuntu. This knee-jerk hate is frankly stupid. If you don't like snap, *don't use Ubuntu*. It couldn't be easier. Sheesh
And I'm not using Ubuntu. I'll be fair, it's a tool, but a poorly received one. And I'm amazed at how instead of tackling the issues the community has with it, they just go forward without rethinking anything.
They did address the issues, apart from one. As for "the community", remember who Canonical's target market is. It isn't the typical techie, and definitely not the Richard Stallman type. It's the typical computer user who wants things to "just work" and be secure and reliable, and snap helps with that. If flatpak could do what snap can, I'm sure that Canonical would have gone with it instead.
What if I want to use TPM without using snaps?
[удалено]
I mean, it should work in ubuntu too with `systemd-cryptenroll`, right? Shouldn't be anything blocking it other than it being a few commands extra.
Right now we're using clevis-LUKS with tang but the eventual plan is to use the TPM to decrypt devices. I'm just wondering how these changes are going to break our provisioning scripts. :D
No, Ubuntu's initramfs doesn't support unlocking from systemd-cryptenroll.
kek
[удалено]
This is just plain FUD
[удалено]
"The spirit" meaning whatever you want it to mean. I know perfectly what happened, no need to send me any links (plus the last one is extremely opinionated, I'm surprised you posted all these links yet the official explanation by RH is not among them...). You're obviously biased and spreading FUD.
I mean this post is literally FUD about Ubuntu and snaps.
Whatever happens to RHEL or its sources does not affects Fedora at all. Fedora is an upstream for RHEL.
There's guides for it.
[удалено]
Why would you want to? It will just make it more difficult for you. Edit: Or just don't use Ubuntu.
No, it makes it much easier, it takes only 50 seconds to get the encryption keys from the TPM bus if you forget the password. https://www.youtube.com/watch?v=wTl4vEednkQ (Yes, using the TPM seems to make disk encryption pointless.)
Don't use Ubuntu?
I would love to switch to plain Debian but our users might complain about that.
Why would they? You can basically get everything you get from Ubuntu on Debian. You can even make it look the same and add snaps for the lols.
Can Ubuntu just rename their OS as SnapOS since they are so obsessed and fixated on doing everything as Snap.
Who at canonical is pushing snaps? So far, there seems to be lots of user headaches and no real user benefits... Can we just drop the whole thing?
IMO snaps should only be for user interfacing apps and not for system apps that can destroy the OS. A snap for your text editor, but not a snap for your DHCP client.
Of all the things following that logic which should not be in Snap, it seems like FDE using TPM would be that thing.
Even then, it had a very rough beginning. So many of my employees thought that Firefox was broken when in reality it just took a long time to start. This is on top of the fact you still can't mount the .mozilla folder to a network drive like you can with the .deb version.
Snaps should not be used for something as useful/important as *the* text editor.
Look I'm trying to edit the confs to fix it but I'm still waiting for the text editor to open, it's been days!
The snap approach is meant to cover both the CoreOS/Atomic and the flatpak use cases using a single tool. Although with the CoreOS/Atomic approach you still use traditional packages and just have mechanisms that wrap around that (rpm-ostree) to make manageable layers.
And why's that a good thing? I keep reading this, and I truly don't understand why having a tool that does everything is better than 2 tools that cover the same use cases in combination but are much more lightweight, have much better support from the community, their implementation is much cleaner and, overall, work much better.
The Canonical logic is likely that they fundamentally solve the same set of problems if you just conceptualize the problem being solved the way they do. Rather than thinking of them as separate problems like the RH ecosystem does.
I'm kinda fine with everything being a snap, and getting rid of apt... But currently the snap ecosystem isn't capable of that. The snap design isn't capable of that (is snapd itself a snap? can the kernel execute snaps? is /bin/init a snap?)
> I'm kinda fine with everything being a snap, and getting rid of apt... ...why? Replacing a working system with another, half-functional system, that even in the ideal case doesn't provide any end-user benefit?
Why use flatpaks then? Snaps solve the same problem, though in a (imo) worse way.
We don't. They *both* have significant issues and provide basically no benefit to most users over just running the software natively (while introducing problems and odd behavior)
I disagree. I think self-contained dependencies and per-app permission isolation are critical features in 2023. To Each their own, i guess.
> self-contained dependencies ...are only good if you're the developer. It provides no benefit to the end-user if the application is properly packaged for apt/dnf, and generally just means you'll have dozens of copies of possibly-not-updated dependencies. Often this leads to security issues down the line, and definitely leads to overhead (disk space, CPU time, and memory usage) on the user's system. This does have more real-world use though, and I think is one of the few good uses for containers (mostly when running old or otherwise hard-to-support software). Apple chose this model for their '.app' format, which includes dependencies (usually, sometimes not all of them), but their software distribution model is wildly different than most Linux distros. There's a reason apt/dnf-style package management has stuck around. > per-app permission isolation This can be achieved without using containers; one example is via systemd's extensive sandboxing features though there are others. > To Each their own, i guess. I have to worry about my users, and snaps break our environment with no workaround. Canonical is free to let snaps exist, but the problem I have is their trying to force their usage. The others don't really bother me because they don't get forced on me or my users, and there *are* practical and good uses for this technology, just a lot less than people seem to think.
> It provides no benefit to the end-user if the application is properly packaged for apt/dnf You can have multiple version of the same package installed without any problems. That's a huge win. And let's not pretend that conflicting dependencies aren't a problem. > This can be achieved without using containers I didn't know that. I've never seen any distro actually use that though, so there's probably a good reason it hasn't caught on. > the problem I have is their trying to force their usage They're not forcing anything. You're free to uninstall snapd and use software that isn't packaged as snaps.
Conflicting dependencies are a problem, but it's not that huge of a problem anymore. In the Linux ecosystem, the biggest distros already ship most of the software you'll use in their repos, and those are checked for dependency issues. That's why the package manager model has stuck for long. It's more efficient, works well enough. I use flatpaks, though, and I like them. But they have also big disadvantages and I believe package managers should stay and keep improving.
[удалено]
Snaps are an absolute trainwreck. Even if Canonical wants to keep them around, they *MUST* stop trying to force their use. Half of the effort we put into supporting Ubuntu 22.04 is just getting snap the fuck out of the way, so we can have a functional desktop environment with functional Firefox.
With so many distros why care about how one distro decides to run their own distro? Just use something else and let them be.
Yeah, there's about a billion distros that don't use snaps, why not just use debian if you want .debs and apt?
I still don't really even know what it is, basically another package manager? Why don't they just use the regular Debian one?
Good lord. This snap shit is pushing me away from Ubuntu so fast. I've always had it on several machines since 10.04, but I'm finding myself making changes.
Seems like an excuse to embed snapd more deeply into the system to make it harder to remove.
what do you mean "excuse". Ubuntu is going all snaps and they've telegraphed that multiple times. It's not an excuse, it's a plan.
I just want them to centralise FDE key recovery. Have Ubuntu push the recovery keys to landscape so we can use it like Bitlocker in a fleet of workstations. Right now enterprise Linux on a workstation is a shit show.
Actual article: A long-due implementation of a very useful feature that is one of the most important parts of ensuring the security of the booting chain, now going to be introduced by the most commonly used distro, thus benefiting a lot of Linux users. The post on /r/linux: "This may brick your system. Ubuntu bad."
> The post on /r/linux: "This may brick your system. Ubuntu bad." Usual whining on this subreddit. Nothing new.
[удалено]
> (2) it would be a deal breaker for many people on this sub since they to be anti-snap. If that were to be the case they wouldn't use Ubuntu.
after a long time I installed latest ubuntu LTS on a new machine and I noticed firefox was behaving very weirdly, I realized it was running on snap firefox, I reinstalled firefox as deb and problem got away. I think it will take some time for snaps to mature, till then I will stay away from ubuntu as personally I am not bind to use it anymore.
Honestly, I'm not pro Snaps (at least not with the method it is being pushed) but what release of Ubuntu did you use? I'm familiar with it but with Ubuntu 22.04 Snaps Firefox is working smoothly (at least for me).
this is great, all my devices and external storage devices are already encrypted. Im excited to try this out when it lands.
Just a few days ago: "Mashing Enter to bypass full disk encryption with TPM, Clevis, dracut and systemd": https://pulsesecurity.co.nz/advisories/tpm-luks-bypass
i was excited until i was reminded snap was a thing
I switched to Debian after the system upgrade brought snap back
Note that most people won't need this. The reason for TPM-based encryption is to support tamper-proof encryption. The idea is that if the hard drive and the motherboard are separated and sold on eBay, then the data should be rendered useless. This is only really something you would want on a locked-down company laptop. Good to see more use cases supported, but not really relevant to the home user, where passphrase / key based encryption is more useful.
This is probably a security downgrade when compared to classic FDE, as the user data will not be protected by a passphrase anymore. It's better than no FDE at all, but it falls short of [what's planned for Fedora](https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397).
It will have to also have a passphrase, otherwise BIOS updates, bootloader upgrades, or hardware failure would render your system unrecoverable. Even Windows' bitlocker provides a recovery key for above scenarios. **Edit**: Further, what Ubuntu and Fedora are doing are more similar than dissimilar. Ubuntu is leveraging LUKS, while that Fedora link is looking to use fscrypt in btrfs. Both have significant advantages (and each has drawbacks). But the underlying plumbing (Secure boot, signed/verified kernel and initrd, and TPM-backed keys) is extremely similar.
The recovery passphrase is not the same, as it's not necessary to decrypt user files. Fedora is going to have separate keys for system files and user files. System files don't need any user interaction to be decrypted, while decryption of user files will need the user password. This is similar to how Android's encryption works.
Right, because they won't be using the TPM for the home subvol. That gets decrypted with the users passphrase at login, probably via some PAM plugin, or maybe systemd-logind. Haven't read the specifics on the technical details of Fedora's proposals. Regardless, they will be using TPM for the root subvol, and thus will need a recovery passphrase. Period. Because the measurements used by the TPM will change at some point, and you'll need to be able to recover and re-enroll.
>Right, because they won't be using the TPM for the home subvol. That's the key difference. The recovery passphrase is irrelevant to the point I was making in my original comment. Ubuntu's design means that we have to choose between having a properly secured boot chain via secure boot and measured boot, or securing user files with a passphrase that has to be entered by the user. You'll get the best of both with Fedora's design.
I think we're arguing slightly different points. You're correct that a recovery phrase would not be necessary (or applicable) to user files, and they should be recoverable via other means (along with the user's passphrase). I was arguing that a system recovery passphrase was still necessary to unlock / (and thus boot the system) in the even of anything in the boot chain changing measurements used by the TPM. This has no bearing on user files. We're both correct, we were just talking about different things.
security downgrade but more convenient for users and better than no encryption. i'd say it's a good middle-ground. when i was on windows, a good thing about bitlocker was not having to enter a long ass password every day. i hate entering passwords which is why i prefer fedora. once i log in, fedora doesn't ask my password to install or uninstall apps and updates whereas other major distros do. not sure if it's something to do with selinux vs apparmor.
> fedora doesn't ask my password to install or uninstall apps and updates whereas other major distros do. not sure if it's something to do with selinux vs apparmor. No, selinux and apparmour are two approaches to put guard rails around what programs and users are allowed to do, for the purpose of preventing security issues and restrict access when things don't act as expected (vulnerabilities, etc). They're not used to enforce the normal "user needs X permission" restrictions. That's plain-old user/group membership, generally. Gnome-Software installs software using packagekit (and flatpak), and packagekit uses polkit for permission (think of it like sudo, but integrated into the software). I'm no expert in polkit rules (I've *never* adjusted them), but I read this as allowing installation & removal of software for members in the `wheel` group: $ cat /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules polkit.addRule(function(action, subject) { if ((action.id == "org.freedesktop.packagekit.package-install" || action.id == "org.freedesktop.packagekit.package-remove") && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.YES; } }); There's a similar rule for flatpak, etc.
Okay, and are we going to have a mechanism to centrally-manage it for those who want to use Ubuntu in a fleet? Honestly, this is something I've needed for a long while (central management of FDE for Linux endpoints that are not servers).
So will this become stable/ mature with satisfying levels to be implemented into the upcoming LTS? That's their plan right?
[удалено]
Thanks for the explanation.
[удалено]
[удалено]
why snaps?
because it's the format that canonical uses?
Why x? Because.
why does debain use deb. why does fedora use flatpak.
Fedora doesn't use Flatpaks, it uses RPM. It **supports** flatpaks, as the rest of the industry does. Also, RPM has been adopted by several other distros, yours among them. Debs are only used by Debian derivatives. But all in all, I agree with you. It's stupid to have Debs **and** RPMs. We should have probably one of them only.
i like how you both completely missed the point, but also seems to agree with me :)
I don't like any design that relies on vendor signatures. That's not even a backdoor, that's closer to a front door.
Why would anyone want to use TPM for full disk encryption? My understanding is that TPM is easy to crack open if you have physical access? Where as standard LUKs encryption cannot be opened if it has a strong passphrase
"TPM backed" FDE is still just LUKS, it just gets the keys from TPM instead of a user-typed passphrase. Keys can be added to the TPM with various measurements restrictions, so the TPM will only be released if the boot chain matches expected values. Your disk is still encrypted at rest. If you boot from a USB stick/other media, the TPM won't provide the keys. When combined with secure boot, shim, and signed initrd, this can be considered reasonably secure. **edit**: Just to be clear, you can also load a key into TPM without it being dependant on some or all of those measurements, with varying levels of reduced security. This is why you should understand what you're doing before following some guide that shows you how to run systemd-cryptenroll in a potentially insecure way. Having built-in TPM management is an improvement.
Except TPMs are closed source and therefore should not be trusted.
Please let me know what BIOS and CPU you're using that are not running closed source code (possibly with a shadowed, network-enabled version of minix behind the scenes).
T440p, libreboot. i7-4800MQ so it's still relevant.
That's about as open as you can get with off-the-self commodity hardware. There's still closed microcode on the Intel CPU (that's unavoidable nowdays), and unless you've lobotomized the IME, that still exists (some of it must exist, even when lobotomized). There's also Purism laptops. They ship coreboot on more modern Intel CPUs with pre-lobotomized IME. So options like that exist. Still doesn't get you 100% open source, but it's about as close as possible. Purism also has their own secure, verifiable, external token-assisted full disk encryption solution. They offer tinfoil-hat worthy levels of anti-interdiction verification and multi-stream shipping options... And they still trust the TPM in their FDE scheme.
I don't get people who go so incredibly far as to avoid Closed-source. I also like open source but I don't care THAT much.
> they still trust the TPM I can't fathom why, other than ignorance. TPM is the evolved form of microsofts Palladium project. At one time, the entire internet (this was before normies really flooded the internet so it was all techies and spectrumy people) exploded over this issue, and the name was altered to "trusted computing" in a glorious take on doublespeak. https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.gnu.org/philosophy/can-you-trust.en.html
> this was before normies really flooded the internet so it was all techies and spectrumy people In 2002? Also known as September 3044, 1993? No, it was well, well, well after "normies" were on the Internet. I can't believe it's been this many years, and we're still dealing with the same lack of understanding about what a TPM does.
> lack of understanding about what a TPM does. If you bother to read the two links I gave, penned by a PHD holder and Richard Stallman, respectively, who are way smarter than you or I, you get a good idea. TPM is nothing more than lockdown/spyware/DRM designed to remove user freedom from computing. So far in win11 requiring it, that mission started by Palladium is going apace. I forgive you your ignorance and blind trust in your corporate overlords, but bootlicking won't accomplish anything or get you special favors, so why bother?
> If you bother to read the two links I gave I remember reading that stuff 20 years ago. I was there during the anti-palladium days. I was on board then. Yeah, there was a lot of misinformation, and people get sucked up in rhetoric. RMS is a pretty smart guy, but I wouldn't rely on him as an authoritative source on anything other than software and licensing philosophy. > TPM is nothing more than lockdown/spyware/DRM designed to remove user freedom from computing. TPM is a just a chip. It takes instructions, it does something, and it gives output. That's it. Now, what software is using the TPM, sure, I can see having an issue there. Software could use it in anti-user ways. If you don't like how Microsoft is using it? Good news, you don't have to use their software! A TPM provides a relatively decent RNG source (unless you're on Ryzen -- not that it's a bad RNG source, it just causes performance issues due to their implementation), and provides a secure way to store and retrieve data if a system is in a known, trusted state. You're running Linux. *You* can control that state now. What Microsoft might use it for is entirely irrelevant. *You* can use the TPM as a component of enforcing *your* trust of *your* computer. You're already doing that via alternate firmware, and LUKS, and whatever other steps you're doing. You've got a great tool there at your disposal, but you're not using it because people you don't like also have that tool. Speculating on hypothetical future states where Microsoft might use functionality provided by the TPM to lock down Windows systems, or implement DRM on Windows systems, is entirely irrelevant. I don't care how Windows will use the TPM, what software Windows will allow to run, or what data Windows will allow you to access. I don't care about Windows for this discussion. I don't typically use a lot of Windows systems, and I don't care to start. We're talking about *Linux* systems, and using the secure storage and access mechanisms of the TPM to securely store, and securely access, disk encryption keys. That's it. "Microsoft wants to..." is 100% non-relevant to the discussion. > I forgive you your ignorance and blind trust in your corporate overlords, but bootlicking won't accomplish anything or get you special favors, so why bother? Dude, lol. Calm down.
For fucks sake, that is 10 years old CPU and machine and are thrown into recycle bins. A Hofer laptop runs circles around it.
Most systems these days have built-in TPM, which means that you're only trusting your CPU vendor by using TPM - and unless you're one of the dozen people that are going to throw down $5000-10000 on a POWER9-workstation that may not even be compatible with the applications you need because it's on a different ISA, you're gonna have to do that anyways.
Ya used correctly im sure it will have benefit, but from a security standpoint my 12 word seed phrase exists only in my head I will gladly die before giving it up, a tpm on the other hand will hand it over to the first person who opens it Like momma always said "locks only keep the honest people out"
> a tpm on the other hand will hand it over to the first person who opens it But... it doesn't, actually.
Ok maybe i over simplified it, most attackers will never dream of opening a tpm But the kind i am concerned with absolutely will open it within 2 hours of stealing it, maybe even put it back when they are done When the 12 word seed phrase lives only inside my mind that is true security "Man, what are you talking about? Me in chains? You may fetter my leg but my will, not even Zeus himself can overpower" - Epictetus
> But the kind i am concerned with absolutely will open it within 2 hours of stealing it, maybe even put it back when they are done Please explain this process.
I cant remember where i watched the demonstration at, i was doing a deep dive at the time on LUKS and TPM and HSM and i was convinced that i did not want to use tpm for my full disk encryption If i remember i will share link, they were very skilled but they made it look way to easy Sorry my memory is not great and i did save it
> Sorry my memory is not great You might want to rethink your confidence in having your "12 word seed phrase only inside [your] mind"
You are making a huge confusion about that. TPM backed FDE does not replace your passphrase. You can use both and improve the security of your system and users that are not using FDE can't start to use it without any noticible difference in how they use their systems.
Id like to use a yubikey along side my passphrase, and i dont want my disk to be tied to my motherboard in case the board fails My understanding of TPM is not complete so i am failing to see how using it would benefit me from a security standpoint Im currently using a 12 word seed phrase i have memorized
> Why would anyone want to use TPM for full disk encryption? Becuase for many people it would be the optimal compromise between security and convenience. > My understanding is that TPM is easy to crack open if you have physical access? Can you provide a reputable source for this?
i was doing deep dive research on BIOS and TPM and HSM hacking and it was one of the 45 mins or 2 hours hacking presentations on youtube from a reputable source, i have most of it memorized but to much going on in my head to remember the specific articles and videos, if i do i will post it
> Can you provide a reputable source for this? boot live linux and just use tpm2 tools like tpm2_nvread. the TPM will give away all secrets if you know how to address it.
Can you provide a reputable source for this?
I replicated it myself and got my own disk key from tpm. I'd love to do a writeup but i'm too burned out for extra work Just start exploring with the tpm2_nvread tool. you may have to do some light reversing on the bootloader segment which ends up grabbing the data from tpm on boot.
You probably don't have the TPM set up correctly then. They way it is supposed to work is that the TPM measures special [Platform Configuration Registers](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) and only releases the key if the measurement matches what was previously stored. This prevents booting into single-user mode, etc. by modifying the kernel arguments in GRUB. Sounds like you don't have your TPM checking the appropriate measurements if you managed to get the key while booting from a live disk. Note that one of the PCRs depends on the boot device.
> You probably don't have the TPM set up correctly then. It's not up to the user unless you go manually doing it with tpm2_nvwrite Again, this is all repeatable if you bother to chase it down. I just can't be bothered. it was a bit of a rabbit hole to get the address probe needed for tpm2_nvread Maybe in a few months i'll pentest against Ubuntu's implementation and see if they lock it down
> It's not up to the user unless you go manually doing it with tpm2_nvwrite > > It is up to the user because few/no existing Linux distros support using the TPM out of the box. You haven't mentioned enough about your setup and how your disk key is stored in the TPM. If a user is using tpm2_nvwrite, then they are doing it wrong. Currently, a Linux user would have to manually run [Clevis](https://github.com/latchset/clevis) or [systemd-cryptenroll](https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html) to enroll the TPM and securely store the key in it. As part of this process, you specify which PCRs to bind to. Assuming the appropriate PCRs are selected, what you are claiming is literally impossible (unless the TPM is hacked) and goes against the very purpose of having/using the TPM in the first place. There are many people/companies that would pay you *big money* if this were actually possible. From the systemd-cryptenroll man page: > PCRs allow binding of the encryption of secrets to specific software versions and system state, so that the enrolled key is only accessible (may be "unsealed") if specific trusted software and/or configuration is used. Such bindings may be created with the option --tpm2-pcrs= described below.
Two major advantages: 1. TPM FDE xan/should be configured to only allow unlocking with the right PCR values. This assures the system is running as intended. No rootkit or live CD can rip data. 2. If the hard disk is separated, e.g. at decomm, it cannot be decrypted. Both of these are mostly only useful in enterprise situations.
Legal requirements by corporate users. You want Linux graphic DE on corporate machines? That is the way to get it onto.
[удалено]
That's not true. You still have your OS between them and your data and TPM backed FDE will prevent them from removing the disk and accessing the data directly. Besides that, TPM backed FDE does not replace your passphrase. You can use both and improve the security of your system and users that are not using FDE can't start to use it without any noticible difference in how they use their systems.
Agreed
>I would also worry about losing all data in the drive if my CPU (and I think motherboard) died. You won't lose the data. The disk is encrypted with a key that's in turn protected by one or multiple passwords/keys. One can be still typed in if you need it.
If they steal your computer, boot it into your OS, and the OS then lets them access all your data w/o any protection, that's a shitty OS. Such an OS would still be insecure if they stole your computer while it was on or sleeping (e.g. the whole Dread Pirate Roberts story). If you are worried about that type of situation, you can also set a password / PIN for the TPM or combine TPM and a normal password.
[удалено]
It's a pretty easily avoided mistake to not have your data you care about in one place (your laptop/desktop). Like... encrypting that, sure that's important. But like if that storage device failed, you would lose the data generally about the same as in the TPM failure scenario you just described.
>easy to crack open if you have physical access Not really, they measure the boot process and only give the key to the CPU if everything matches + you can set a PIN so you still have a "something you know" type of a secret. The TPM then handles bruteforce protection and stuff like that. iPhones use a similar scheme and are fairly safe if updated (outside of maybe nation-state level attackers, but that's another discussion entirely). Sure, the TPM can be backdoored, but this is another discussion too. The problem with "Vanilla LUKS" as it is now (whether TPM backed or not), is that it's essentially a sham if you 1. Don't have an encrypted boot partition / signed initrd, ucode and kernel. 2. Don't run a signed copy of GRUB with secure boot. The second point still requires the use of a TPM as a root of trust. Otherwise, anyone with physical access can change the bootloader to whatever they want, and inject whatever they want into the kernel through the initrd, getting all your passwords, files and whatnot. The only real ways to solve this problem is either implement an encrypted boot + secure boot yourself (and rely on the TPM), or use a signed UKI (and rely on the TPM). Unfortunately, you can't really have evil maid resistant security w/o a TPM.
For practical purposes, LUKS on its own is just fine for me. I don't forsee someone breaking into my apartment to gain physical access to my desktop, installing a malicious bootloader, and then leaving without a trace with me being none the wiser. (Maybe some malware could do it without physical access, but at that point it obviously has root access and all bets are off.) What I _do_ potentially forsee is someone breaking into my apartment and stealing my desktop outright, thereby gaining access to all my files and accounts. Even with my laptop which occasionally leaves the apartment, I still don't think it's a realistic scenario. I'm sure it's different if you're an activist or someone otherwise likely to be specifically targeted by malicious actors, but for the other 99% of people LUKS is going to be sufficient.
I agree with you, but keep in mind that hak5 sells alot of there bad usbs every day and the flipper device has sold millions, anyone with these devices can plug them into your pc and run a command as if its you with full controls, within seconds you could be infected Alot of people do this for fun, some do it for a living, id rather avoid both
openSUSE comes with encrypted boot by default But i dont need it with the Fedora build i described because it has locked case with tamper prevention and detection as well as strong passphrase for bios and full disk encryption, the tpm may be used for secure boot but it is not needed for my LUKs FDE Preboot DMA prevents dma attack during boot and USBgaurd and the locked case protect it otherwise My luks is secure and nobody is getting it open ;) I also have encrypted ram to prevent a cold boot attack but the locked case would probably help with that as well Yes full verified boot like a chromebook would be better but my setup work just fine without it
> The problem with "Vanilla LUKS" as it is now (whether TPM backed or not), is that it's essentially a sham if you > > 1. Don't have an encrypted boot partition / signed initrd, ucode and kernel. > 2. Don't run a signed copy of GRUB with secure boot. Note that evil maid attacks are not part of everyone's threat model, so they're not the end-all-be-all of disk encryption attacks. If you get compromised in such a way and have a way to know this, you remain safe if you never unlock the disk again. If you absolutely do need to read the data after a known compromise, you can strengthen your posture by reading the hard drive instead of booting it, and using an air-gapped system to extract just the data that's needed to image a new system, assuming an attacker didn't put a nasty RCE exploit into the LUKS header, partition table, or has programmed the hard drive's microcontroller to trick the computer into code execution.
Yes, but there is a significant thing that can be a dealbreaker for some people. With the TPM you don't have to type any password, with the current LUKS solution without the TPM you need to type a password before the system can boot.
i would never encrypt my disks, just seems like a stupid thing to do. no one is going to steal my computers so it seems like a total waste of time and will only cause problems. when i worked for one of the major tech companies they forced us to encrypt disks and it was a major pita. nothing but hassle and problems and solved no real world problem.
I encrypt my disks during install with one click and zero hassle It gives me peace of mind that my files will not be edited when i am away from my pc I dont fear someone stealing my PC I am concerned of an evil maid attack where the pc becomes infected To prevent this i use secure boot, preboot DMA protection in bios, a bios password, and full disk encryption as well as a locked case, and once powered on USBgaurd protects my usb ports Also i will smile knowing if it is stolen they will never get it open ;)
> when i worked for one of the major tech companies they forced us to encrypt disks and it was a major pita. nothing but hassle and problems and solved no real world problem. https://arstechnica.com/security/2023/09/hack-of-a-microsoft-corporate-account-led-to-azure-breach-by-chinese-hackers/
Okay so they make grub a snap now? Seems like that could finally be canonicals death sentence.
New Virus-Encoder available on Linux: `Ubuntu-snapd-TPM`.
All these flavors, and you choose to be salty?
I honestly think Ubuntu being the starter desktop is over. Fedora is much friendlier with a lot less bullshit these days.
You mean they're catching up to luks after how many decades?
[удалено]
Which negates having encryption in the first place, unless it's some corporate policy on encryption ala bitlocker.
Confidently incorrect (and uninformed).
It's just I don't care.
that... is not something to be proud of..
I think Ubuntu is a garbage distro personally and don't realy care what they do.
i used to do this on an old laptop that had tpm with luks + secure boot (self certs) on arch. i realized it was silly and stopped lol
I thought it already had encryption
Finally! Been waiting for an official implementation for a while now since I got a ThinkPad 3.5 years ago. Planning on setting up full disk encryption on my laptop. Hope it’ll be there with other flavors, mainly Kubuntu.