7 ms·

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,

by alekq 3y ago

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)?

2devnull 3y ago
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 3y ago
  How do you work with a computer you don't trust?
Arnavion 3y ago
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.
- akvadrako 3y ago
  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 3y ago
    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 3y ago
    But a user has to know to look for these alternatives. Use a distro you trust and you don't have to.
- TommyTran732 3y ago
  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 3y ago
    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.
- audidude 3y ago
  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 https://github.com/flathub/org.audacityteam.Audacity
kramerger 3y ago
> 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 3y ago
  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 https://www.rust-lang.org/tools/install curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh At least it does not require sudo (unless that's buried in the script.)
  - steveklabnik 3y ago
    It does not require sudo, by design.
- alekq 3y ago
  Usually I look for alternative way - like zipped binaries or similar. Most of the developers offer it.
- eeZah7Ux 3y ago
  Stay away from them.
mid-kid 3y ago
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.
lostmsu 3y ago
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.
- mjg59 3y ago
  The TPM isn't involved in secure boot. Could you provide some more details about what went wrong?
  - lostmsu 3y ago
    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/777e8b52c8d88eb87467935769c98a95#enroll-your-encrypted-volumes https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a... , the bit "then auto volume decryption on your next reboot will fail". This makes sense.
    - mjg59 3y ago
      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 3y ago
        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 3y ago
        If you have secure boot enabled, how does the attacker replace the kernel or bootloader?
NoZebra120vClip 3y ago
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.
w0m 3y ago
>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.

by alekq 3y ago

2devnull 3y ago

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 3y ago
How do you work with a computer you don't trust?

Arnavion 3y ago

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.

akvadrako 3y ago
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 3y ago
  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 3y ago
  But a user has to know to look for these alternatives. Use a distro you trust and you don't have to.
TommyTran732 3y ago
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 3y ago
  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.
audidude 3y ago
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 https://github.com/flathub/org.audacityteam.Audacity

kramerger 3y ago

> 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 3y ago
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 https://www.rust-lang.org/tools/install curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh At least it does not require sudo (unless that's buried in the script.)
- steveklabnik 3y ago
  It does not require sudo, by design.
alekq 3y ago
Usually I look for alternative way - like zipped binaries or similar. Most of the developers offer it.
eeZah7Ux 3y ago
Stay away from them.

mid-kid 3y ago

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.

lostmsu 3y ago

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.

mjg59 3y ago
The TPM isn't involved in secure boot. Could you provide some more details about what went wrong?
- lostmsu 3y ago
  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/777e8b52c8d88eb87467935769c98a95#enroll-your-encrypted-volumes https://gist.github.com/jdoss/777e8b52c8d88eb87467935769c98a... , the bit "then auto volume decryption on your next reboot will fail". This makes sense.
  - mjg59 3y ago
    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 3y ago
      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 3y ago
        If you have secure boot enabled, how does the attacker replace the kernel or bootloader?

NoZebra120vClip 3y ago

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.

w0m 3y ago

>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.