[alekq]

I went this rabbit hole roughly 2 years ago and I just quit at the very end, because my focus went from using the OS for something productive to maintaining it, securing it and becoming home sys admin.

Since then, I’m simply “ignorant” and sane - use it, update it regularly, use official software sources (so official distros repos and Flatpaks), FDE, SecureBoot, do not run random net stuff (like scripts, “Git” etc.), try to stay as default as possible and use a VM to experiment if I really need to.

I am curious - how many of you regular desktop Linux users actually had security issues (or at least suspected something shady)?

[Arnavion]

As great as flatpaks are for providing sandboxing, the problem with them is that they are upstream software. When Audacity added telemetry it only affected binaries downloaded from them, not distro-compiled binaries. When firefox stops you from loading your own extensions, that's because you're using a binary downloaded from them, not distro-compiled binaries. A decade ago I used to think distro package maintainers were unnecessary middlemen who were just introducing failure points (like the Debian openssl fuckup), but today they are truly the last line of defence from malicious upstreams.

Even if something sneaks into a distro package it's possible to convince the distro package maintainer to disable it, because the maintainer's interests are aligned with you and not upstream.

[audidude]

The example you gave, Audacity, has a flatpak managed by one of the flathub admins, and most definitely does not include telemetry.

https://github.com/flathub/org.audacityteam.Audacity

[Arnavion]

1. My point was about using upstream software, not about the Audacity flatpak specifically. Audacity binaries downloaded from upstream's website have the problem I mentioned.

2. The Audacity flatpak is maintained by a Flathub dev only because Audacity upstream has not expressed an interest in maintaining it themselves, not because of some Flathub policy to reject telemetry etc. If they wanted to maintain the flatpak themselves they would be allowed to do that, since Flathub policy is to have upstream developers maintain their flatpaks. And that would lead to the problem I mentioned.

[akvadrako]

But you can get alternatives which have the telemetry removed. Like VSCodium and some Firefox forks. And instead of every distro needing to do those patches themselves, they can share the effort.

[Arnavion]

Maintaining a firefox fork is a much bigger job than putting `--with-unsigned-addon-scopes=app --allow-addon-sideload` in the package build script.

Distros already share effort implicitly because maintainers of distro X often look at what distro Y is doing for that package. Also users compare distros frequently and will tell the maintainer of distro X that the same thing works with distro Y.

[rlpb]

But a user has to know to look for these alternatives. Use a distro you trust and you don't have to.

[iudqnolq]

Conversely Debian broke Firefox's ability to update without requiring a restart.

[kiwijamo]

Can you expand? I thought updates required a restart no matter what platform or distro.

[iudqnolq]

I misremembered. The effect is that you don't get the "Restart required" message, but the implementation is that they just postpone applying the update until your next re-open.

> We also are not trying to force you to install updates before you can keep using Firefox. Firefox's update mechanism downloads updates while it is running and installs them at startup. ... In the case of Bug 1705217, the package manager updates Firefox's files on its own schedule that is outside of Firefox's control ... Firefox had no intention of forcing updates to be installed at an inconvenient time.

https://bugzilla.mozilla.org/show_bug.cgi?id=1761859

[Arnavion]

That is not a difference in behavior between distro packages and upstream Firefox. If an update gets installed then FF requires you to restart it. So just like the upstream binary's updater doesn't install the update while you're still running it, you shouldn't update the distro package while you're still running it either.

[iudqnolq]

No, if you update upstream Firefox you'll see a prompt inviting you to restart when you want. If you update distro Firefox you'll see a page blocking everything telling you you need to update now.

That's because upstream Firefox separates out downloading and applying the update.

[TommyTran732]

This doesn't make *any* sense. Even in the example you gave, Mozilla really wanted to block you from using extensions, they will just remove the entire store.

[Arnavion]

It doesn't make sense because you need to read carefully. I said "loading your own extensions", ie loading extensions not from their store but by dropping a .xpi in /usr/lib/firefox/browser/extensions that you made running `zip` and changing the filename.

[mid-kid]

This is pretty much the best approach, currently, and probably into the far future.

When I need to run a program from a dev I don't fully trust to behave well (e.g. the app is closed source for no particular reason, has known extensive telemetry, or has an unhealthy tendency to fuck with configuration files), I run it in a firejail, container, or reboot to windows.

For everything else I fancy the thought that everything I install being open source and looked at by multiple people including a package maintainer means that there's a significantly lower chance of easily exploitable vulnerabilities (e.g. in system config and general program behaviour), and an almost nonexistent chance of outright malicious code.

[NoZebra120vClip]

I recently shut down my last Linux box and I do not run Linux at home anymore. However, I did run various distros of Linux on the desktop from 1999-2022. Prior to that, I ran Minix and OpenBSD on my desktop machines, starting around 1992. So let's say 30 solid years of Linux on my desktops.

I never ever, never once had any security issue. I never had an issue with malware being installed. I never had an issue with external malicious users accessing my system - not even DDOSing my network.

In fact, I have run Windows as well since version 3.1, and DOS before that, and I've never had a virus or malware on Windows, either. Not a single compromise or glitch at all.

Once, I was a guest at a friend's house and I discovered that he had fallen victim to some sort of replicating virus on his Windows 98 system. I was able to manually eradicate it for him, without resorting to commercial anti-virus software.

A few weeks ago, I did discover that my home router had been compromised and some sort of malicious DNS service had been installed on it. So, I must confess to my first-ever home network compromise, albeit an embedded router OS I had little control over.

[kramerger]

> do not run random net stuff (like scripts, “Git” etc.)

Man, half of the cool tools want me to do this

   curl cool-company.io | sh

[HankB99]

That's how Rust installs. I'm not that happy with it but at the time (years ago) the distro (Debian) packages were incomplete. From https://www.rust-lang.org/tools/install

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

At least it does not require sudo (unless that's buried in the script.)

[steveklabnik]

It does not require sudo, by design.

[alekq]

Usually I look for alternative way - like zipped binaries or similar. Most of the developers offer it.

[eeZah7Ux]

Stay away from them.

[2devnull]

It’s hard to prove a security issue but “shady” describes my experience with most all modern OS’s. I trust Linux the least but it’s my daily driver. I just assume it’s comp’d because at some level (NSA at least) it is. I also try to reinstall a fresh distro at least quarterly, but even on a fresh install don’t trust it. If I can’t trust all of the devices on my network (I don't) then I also don’t trust my network. If that’s true then no device on the network can be trusted. Until I own and administer every device on my network, there’s no way around that. Even if I did trust all the devices I also have to trust the isp and the router manufacturer (which I certainly don’t).

[funcDropShadow]

How do you work with a computer you don't trust?

[w0m]

>I am curious - how many of you regular desktop Linux users actually had security issues (or at least suspected something shady)?

Replace Linux with OSX or even Windows in this statement and i wouldn't expect crazily different results from a crowd that follows the best practices you outlined.

[lostmsu]

Have you got SecureBoot working well on Linux? My last try was with Fedora 34, and I had to manually reinitialize TPM with every kernel upgrade. One of the serious issues that keeps me on Windows.

[yrro]

Don't worry about it: Secure Boot is (currently) 100% pointless on Linux because the initrd is not authenticated.

Once the work described at https://lwn.net/Articles/918909/ this will change, and , and kernel updates should no longer require will (hopefully?) no longer require re-initializing the TPM.

[patrakov]

Well, all my machines use Arch Linux with custom Secure Boot keys and unified kernel images (essentially, the kernel, the initrd, the command line, and the splash screen fused into one EFI executable and signed as a whole). So on my machines, the initrd is definitely verified. Thanks to Foxboron who made this easy with sbctl.

An entirely different matter is that the default Microsoft keys allow running all other distros, with their GRUB which allows to load initrds without authentication - which would allow evil-made style attacks by replacing the whole boot chain and the kernel. So in my world, all builds of Shim and GRUB are malware, and keys that allow booting them are not allowed in the DB.

[mjg59]

The TPM isn't involved in secure boot. Could you provide some more details about what went wrong?

[lostmsu]

It is about full disk encryption with automatic unlock during boot. One needs to make TPM dependent on a successful secure boot to allow access to decryption. The boot completes no problem, but the TPM entry that controls access needs to be manually recreated with each new kernel update.

See https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a... , the bit "then auto volume decryption on your next reboot will fail". This makes sense.

[mjg59]

Using anything other than PCR 7 is going to make it very fragile, yes - I have no idea why that doc is recommending using PCR 4 as well.

[lostmsu]

To defend against an attacker with physical access to an offline machine you need to verify anything that the attacker can overwrite without the encryption key. Aren't bootloader and kernel on the writable unencrypted partition?

[mjg59]

If you have secure boot enabled, how does the attacker replace the kernel or bootloader?

[alekq]

It is just SecureBoot which is officially supported by many mainstream distros.

I unlock encrypted partitions with a passphrase, not TPM.