How is the Linux immutable experience?

GrapheneOS

upstage4186 The available ones do not provide it, and the hardware platforms they support do not provide what's needed to implement it. The software side of things is incomplete but even if it wasn't, it wouldn't be complete without hardware to go along with it. Chromebooks provide a very basic implementation of hardware level verified boot which doesn't really try to defend against the physical attack vector. ChromeOS used to have an advanced implementation at both the hardware and software level but times have changed. It's no longer the bleeding edge and these more traditional desktop distributions and hardware platforms are NOT implementing what ChromeOS / Chromebooks did many years ago.

goskm75f

GrapheneOS So, do you consider MacOS better in terms of security compared to ChromeOS? Or is ChromeOS the best option for security on a PC?

upstage4186

Thanks for explaining. I assume when you're calling these features "incomplete and insecure", you mean when compared against GrapheneOS's implementations, against a state actor for example?

Surely there's still security benefit in using Secureboot with UKIs, EROFS + dm-verity, SELinux (I know it's not as simple as on or off, I'm referring to Fedora's policies) ? Or is it not worth bothering with any of it?

I know these slapped together solutions aren't up to the gold standard of GrapheneOS, btw, but surely using them brings benefits vs not using them at all?

ryrona

upstage4186 Surely there's still security benefit in using Secureboot with UKIs, EROFS + dm-verity

Yes, if you do it right. Assuming the BIOS is securely implemented and fully uncompromised, including that Secure Boot is still enabled with the right keys, this will provide complete verified boot protection, and prevent persistence of malicious code. As long as you are not signing the images from the same system you will run. An attacker advanced enough to compromise an unsigned boot process must not be able to get hold of your Secure Boot signing keys, or they can sign compromised images. Likewise, if you have any unverified data read at all during startup, there might be a vector for an attacker to compromise the system at each boot. In the typical case where an encrypted volume is mounted during boot, and the data of that volume is not verified, an attacker has plenty of opportunities to gain persistence. Ideally, the image you boot should not auto-mount any volume at all, but you do it manually once you have logged in.

Now, the unfortunate situation about desktop and laptop computers are that the vendors typically never care to keep the BIOS up-to-date, so the security can often not be guaranteed. Most desktop and laptop computers also allows for easily disabling Secure Boot if you have physical access to the computer, such as through the BIOS configuration screen, or by jumper resetting the BIOS to default settings to remove any BIOS password that might be configured. So one cannot really trust desktop or laptop computers to offer any real security against a physical attacker, whereas Pixel phones offers strong security against that.

But preventing persistence from a remote attacker alone is very valuable. And even if BIOS unfortunately probably can be compromised, because probably unpatched for long, if BIOS is compromised, you have no security at all anymore. So preventing persistence of compromise at all other levels is still very valuable.

As I see it, we need to have the software implementation in place before we are in a position to try to push hardware vendors to secure the hardware and BIOS too.

upstage4186

ryrona

Yeah this all makes sense. Obviously as a mere end user, there's only so much I can do.. I unfortunately have to rely on the OEM to keep the BIOS reasonably secure and up to date, assuming the BIOS firmware developers even do.

I always tried to create my keys on a separate trusted machine, but then how do I establish a complete chain of trust on that device? Now that I have GrapheneOS, I could perhaps use Termux, but then I would be trusting the Termux developers to not let insecure /compromised packages through.

At some point I have to have a little blind trust in someone. Same is true of this project too, I have to trust the GrapheneOS developers to be doing what they're doing in good faith, even with audits I assume things can be overlooked. Then I have to trust Google with the firmware, etc.

But still, it seems reasonable to use the aforementioned security features vs not using them at all (so long as you're aware or the risks).

n2gwtl

@GrapheneOS, so what you're saying is that macbooks are still the most secure laptops one can buy?

Can anyone from GrapheneOS validate secureblue as a trusted, capable team, even if the implementation isn't complete? I may go for them for a desktop computer.

Open_Source_Enjoyer

mythodical in some cases it can even make it worse due to its promotion of flatpaks.

I'm a big fan of the flatpak format for its sandboxing, but there are still too many core apps being provided by unofficial packagers, and not enough safeguards or verbosity built-in to the flatpak tools. Yes, you can review the build scripts of Flathub apps, and I do for some vital apps, but there really needs to be a better way of tracking changes within the flatpak toolchain. For example, flatpak update should provide an option to display a diff of the build script for each updated application. Users could then review the build script upon first installation and more easily monitor any changes between updates. I think the flatpak platform is the future for general Linux users, but we've got a ways to go before I would consider it "secure".

To my knowledge, flatpacks (and maybe snaps) are alternativeless if you don't want to give an application full access to your system.
Or do you know any other usable ways of running application that arent flatpacks in a sandbox?

I know that their are things like firejail, but with firejail you have too many issues like:

You need to use the terminal for every application start
You need to remeber to use the firejail prefix
If you forget 1. or 2. only one time and the application is actually malicious, this would be enough for it to screw you.
You need to study all the firejail commands to properly sandbox application, unlike with flatpacks where you just can use Flatseal.

ryrona

Open_Source_Enjoyer To my knowledge, flatpacks (and maybe snaps) are alternativeless if you don't want to give an application full access to your system.

As far as I know, the sandboxing in FlatPak apps is opt-in, and it is the app developer that defines whether the app should be sandboxed or not. You as the end-user have no control over this. This makes it a really weak sandbox. It says so both on FlatPak's official website, and in SecureBlue documentation.

Open_Source_Enjoyer Or do you know any other usable ways of running application that arent flatpacks in a sandbox?

QubesOS provides a very strong sandbox for apps, far stronger than even GrapheneOS offers, and is able to run almost all Linux apps just fine, more apps than FlatPak even has packaged I guess. Unfortunately GPU acceleration does not work in that sandbox at all, and RAM memory overhead is huge, and it is a bit hard to use although not as hard as Firejail I guess, but the sandbox should be close to impossible to escape.

mythodical

Open_Source_Enjoyer ...if you only need a script to auto convert software that normally only exists as (for example) rpm to flatpack, then I don't understand why not more developers just do this, instead of waiting for someone to do it unnofficial.

Unfortunately, creating a flatpak is much more involved than this and it requires detailed knowledge of an otherwise unique build & deployment process. This friction is likely the reason why more developers haven't jumped on board yet.

Open_Source_Enjoyer I occasionaly get random bugs into my system, for example my wifi sometimes donesn't work, or every 15 minutes localsearch-3 is starting to run with high CPU usage witch turn on my fans and drains my laptops battery very fast.
I hope this gets better with immutable distributions.

Using an atomic or immutable distro won't inherently resolve these issues, but they will allow you to easily rollback to a previous deployment for cases where the issue was introduced by a system update. You can also temporarily rebase to a testing release in order to resolve an issue, for cases where the bug fix is available in testing but not yet in stable.

Open_Source_Enjoyer To my knowledge, flatpacks (and maybe snaps) are alternativeless if you don't want to give an application full access to your system.
Or do you know any other usable ways of running application that arent flatpacks in a sandbox?

Flatpaks are arguably the most popular way for end users to sandbox applications, however a virtual machine (VM) provides even more isolation from the host machine, as the entire OS is virtualized. VMs are inherently slower than flatpaks though, and a lot more overhead is involved.

Containers (like those managed by Podman or Docker) can also provide isolation from the host, and generally fall somewhere between flatpaks and VMs in terms of security.

ryrona As far as I know, the sandboxing in FlatPak apps is opt-in, and it is the app developer that defines whether the app should be sandboxed or not. You as the end-user have no control over this. This makes it a really weak sandbox. It says so both on FlatPak's official website, and in SecureBlue documentation.

The Flatpak sandbox is not optional; a developer or end user can choose less-restrictive permissions but cannot omit the sandbox entirely. Secureblue's documentation mentions that the sandbox can be weak, depending on the default permissions selected.

End users also have control over the sandbox settings, with Flatseal being the most common tool used to modify the sandbox permissions.

GrapheneOS

ryrona

As far as I know, the sandboxing in FlatPak apps is opt-in, and it is the app developer that defines whether the app should be sandboxed or not. You as the end-user have no control over this. This makes it a really weak sandbox. It says so both on FlatPak's official website, and in SecureBlue documentation.

There are some things which can be controlled but applications will assume they have them.

Elgoog

Am I correct in understanding that if the physical security of one's computer is certain, then secure boot provides no benefit?

GrapheneOS

Elgoog Linux and Windows desktop secure boot doesn't work against physical attackers. The main purpose of it is reducing where remote attacks can easily persist. It is not a proper or full implementation on the vast majority of desktops and laptops.

A serious implementation of secure boot such as on iPhones or GrapheneOS on a Pixel defends against both remote attack persistence and physical attacks.

cuckflared

So what would be the most secure hardware + software solution for work and private stuff? I've heard that some laptops from Dell or HP can offer HSI-4 security level. Does it matter? If so, is there a good OS that can match this hardware security? Secureblue, Qubes, Kicksecure?

If HSI-4 doesn't provide real security, does it make it at least more difficult for a moderately skilled intruder to perform DMA or Evil Maid attacks? E.g. the memory is encrypted so memory dump should be useless.

Regarding Flatpak, currently it seems to be insecure and not very actively developed. Not sure if there is an easy and reliable way to sandbox apps on Linux that just works OOTB like in Android. There are multiple approaches (AppArmor, SELinux etc.) but no distro seems to confine entire system. Maybe except Fedora and openSUSE which no now use SELinux and seem to cover also user apps.

upstage4186

cuckflared There isn't really a complete security picture for Linux yet, especially when compared to GrapheneOS on Pixels.

Dell and Lenovo are good because of the regular firmware updates, and SecureBoot with easily installable user certs.

Pair one of them with Intel vPro for intel TXT and their encrypted memory support, with TrenchBoot, that'll give you DRTM, which reinits the CPU into a measured trusted boot environment. Enroll your LUKS encryption into this.

Remote attestation is possible AFAIK but I've never looked into it personally.

AMD has the SKINIT instruction (forgot the brand name) for DRTM but I don't trust AMD after learning how easily their SME (memory encryption)/TEE was broken in December. Plus TrenchBoot doesn't support AMD yet.

Its a shame encrypted VMs (one key per VM) are only available on server CPUs.

There's Firejail which provides a nice set of policies for many many apps, but it has security implications (can be partially mitigated with force-nonewprivs option). Flatpak behind the scenes uses bubblewrap which is a minimal sandboxing app, you can create your own wrappers using this, but it's more work. At least with bwrap you get to use your distro's packages though, which forgoes having to add another trusted party(s) into the supply chain.

I use apparmor.d which is a massive collection of rules for AppArmor. But this isn't sandboxing, it's a mandatory access control system.

I don't think secureblue is truly immutable? Unless they've switched to composefs, all they're doing is setting chattr +i /. Kicksecure uses debian and frozen outdated packages. QubesOS is nice but has massive usability issues (no gaming, wayland sucks afaik).

You can do a lot to harden Linux, including the kernel (e.g. https://github.com/a13xp0p0v/kernel-hardening-checker), but creating a GrapheneOS equivalent is a very piecemeal situation, and even if you know exactly what you're doing, it still won't be up to the same standard, with stuff missing. You have to pick and choose your wins, e.g. Arch doesn't compile their packages with CFI afaik, but Chimera Linux does. But Chimera doesn't support any MAC systems, whereas Arch does. It's a mess.

graphuser

@GrapheneOS a variation on immutable distros, id be curious to hear your thoughts on my setup:

one "admin" user with sudo rights for specific commands without passwords
root account for the rest, only possible to login with yubikey from tty
one normal user for browsing etc.
most hardening done by secureblue, and other such distros on top of minimal Fedora install

Boot chain :

secure boot + own keys + pw protected bios and no boot device except internal drive
systemd-boot + uki, both signed
tpm + pin + most PCRs so that its only unlocked in initram stage
IMA sign for all binaries exec'd and mmap'd by root (this leaves out shell script sourced but that seems quite good still since that should mean binaries can be trusted). IMA is some degree of immutability since all binaries need to be signed and cannot be later changed.

It's little documented and a bit painful to set up but Fedora sign all binaries with IMA keys on their build systems (+ created my own key for the usual custom scripts).

For now EFI key and IMA key are on the same laptop but encrypted and password kept inside a vault which needs yubikey to unlock - done adhoc during kernel update.

Open_Source_Enjoyer

mythodical Unfortunately, creating a flatpak is much more involved than this and it requires detailed knowledge of an otherwise unique build & deployment process. This friction is likely the reason why more developers haven't jumped on board yet.

So what is with this flatpack building scripts?

mythodical Using an atomic or immutable distro won't inherently resolve these issues, but they will allow you to easily rollback to a previous deployment for cases where the issue was introduced by a system update. You can also temporarily rebase to a testing release in order to resolve an issue, for cases where the bug fix is available in testing but not yet in stable.

But I can't stay for ever on a rollbacked version, because this would open my system up to security risks arent't it?

mythodical Containers (like those managed by Podman or Docker) can also provide isolation from the host, and generally fall somewhere between flatpaks and VMs in terms of security.

I researched on this but it seems that I have to configure everything per command line.
Don't get me wrong, I don't have command line phobia but I don't think it would be so secure if the security is depending on me memorising and understanding all the commands, this is the same issue that I have with Firejail.

mythodical End users also have control over the sandbox settings, with Flatseal being the most common tool used to modify the sandbox permissions.

Yes and this is the way of sandboxing that would be good for most end users.
Of course it would be even better when permission become more opt in (like with Android) instead of opt out like it is with Flatseal.

ryrona

I just posted a write-up about how to create a fully immutable Linux image, fully verified using Secure Boot with only your own signing key enrolled. There is instructions to replicate my proof-of-concept too. I posted it over at QubesOS forum, since it is more on-topic there, but I will link to it from here as I guess there might be some here that would be interested in reading it.

https://forum.qubes-os.org/t/building-a-fully-immutable-linux-os-image-fully-verified-with-your-own-secure-boot-key/34412

There is a little bit of discussion how it would be practically implementable by an OS vendor, and even QubesOS specifically. And how crucial it is that the BIOS is secure, and not like MSI that writes to the TPM PCR registers that Secure Boot is enabled when it effectively isn't. There is a little bit discussion about protecting against physical attackers and attesting system security too, even if the only in-scope part pf my proof-of-concept was protecting against malware persistence.

wuseman

goskm75f
The GrapheneOS devs have posted about this before. ChromeOS is as good as it gets on desktop, but still a far cry from mobile operating systems.

2WsF

It sounds like for a top-tier secure desktop experience, android convergence may actually be a really good option? With the new desktop mode in Android 16, that may be a feasible option soon, especially for people who don't use their computer for processing heavy things.

For pre-pixel 8 phones that don't have displayport output, are there any options for using your phone with a monitor and keyboard?

« Previous Page