this post was submitted on 06 Aug 2023
98 points (92.2% liked)

Linux

48102 readers
1011 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Do you have any antivirus recomendations for Linux.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 26 points 1 year ago (8 children)

There's plenty of good advice in other comments in this topic. Let me add mine too, something I haven't seen in other comments: You need to figure out your threat model, and steer your course accordingly.

Who do you trust?

  • No one? Don't use a computer. Use an airgapped computer without any internet connection. Write your own OS (but be mindful of bootstrapping issues, you'll also need to write your own compiler to protect against Thompson's hack). It's a hassle.
  • Original authors of software? Compile and install all software from source. Consider using LFS. It's a hassle.
  • Maintainers of my operating system of choice? Only install packages from official package repositories (apt in Debian, pacman in Arch, you know the drill). Eschew any others, like PPA in Ubuntu, AUR in Arch. Though package maintainers don't necessarily review any package updates, there's a chance they just might. Though package maintainers are in the position to inject backdoors during packaging, this is somewhat unlikely as packaging scripts tend to be small and easy to review.

What risky activities are you doing?

  • Running random crap software downloaded from the internet?
    • Run it in a virtual machine. It's easy to install another Linux into a VM - you could try VirtualBox or qemu or libvirt or some other one.
    • Containerize it with Docker, or run it in Firejail or Bubblewrap
      • Don't mount your home directory, or anything other important into the container. Instead, if you need to pass data, use a dedicated directory.
      • It's easy to restrict internet access to a program, when running it in Docker or Bubblewrap.
  • Running the same as root? I'm pretty sure a full virtual machine would be the only secure option to do that, and I'm 100% certain even that would be enough.
  • Running large software that probably ought to be OK, but you never know for certain? This is what I normally do:
    • Use the Flatpak version, if available. Check its permissions (e.g. with Flatseal), you might be able to tighten the screws. For example, a browser (yes, Firefox, Thunderbird, Chromium are available as Flatpaks. Even Chrome is) is plenty large enough for any number of security bugs to hide in. Or a backdoor, which might be crafted to be indistinguishable from a honest bug.
    • If there's no Flatpak version available, I Bubblewrap it.

I have a simple Bash script that restricts apps' view of my filesystem, and cuts off as much stuff as possible, while retaining the app's ability to run. Works with Wayland and console apps, optionally with Xorg apps if I set a flag. Network access requires its own flag.

I could share my Bubblewrapping script, if there's interest.

[–] [email protected] 3 points 1 year ago (2 children)

Thanks for the helpful list. I had concerns in the past about flatpak, because as far as I know the dependencies are bundled into the flatpak and are not using the latest version of your distro. But that means that some flatpaks probably use outdated and unsecure dependencies.

Whats your opinion on that matter?

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

I found flatpak to in fact be ahead of distros' packages. Granted, I use distros that are rather conservative on update (Debian, Gentoo, and Linux Mint). If you use something bleeding edge like Arch, things may be different, but shouldn't be far off.

Either way, I find flatpak to be reliable.

[–] [email protected] 3 points 1 year ago

Indeed, Flatpak is its own repo. It might be more, or it might be less up to date than your favorite distro. Debian, for instance, was once notorious for packaging ancient versions (tho this has improved lately).

The saving grace of Flatpak is that it's still better isolated.

If native Chrome decides to start emitting your crypto wallet's privkeys as a part of its push for Better Customer Experience and More Precisely Targeted Ads, you won't even know or notice it. This is technically very easy to do. It might make itself hard to dislodge by injecting itself into ~/.bashrc or the desktop environment's startup system, or Systemd services.

If Flatpakked Chrome starts misbehaving, it might mine crypto on your CPU (wasting your electricity), or rent out all your disk space, or turn your PC into a node in a botnet, but it won't have access to read or write anything other than your ~/Downloads. It's also easy to uninstall, as it hasn't had a chance to spread its seed.

Sorry for the long rant... What was the original question again? Outdated dependencies? Not an expert, but I hear the whole reason AppImage, Snap, FlatPak, Yarn locks and Go language was invented was to make it easier to have outdated dependencies. You never know what's available in $Distribution, you depend on goodwill of maintainers of $Distribution to package your app and all deps. In AUR you can find older versions of Lua libs (lua51-filesystem) which someone had to add to make Mudlet run - Mudlet didn't see fit to upgrade to the latest Lua.

While it is indeed somewhat true that a library (that many apps depend on) can be patched to fix a security issue, and apps won't need to be rebuilt, it only works if the lib was a sufficiently recent version. And if the distro maintainer is more diligent than the Flatpak maintainer. Otherwise, the authors of said lib are going to ask you to upgrade to a supported version where that bug has already been fixed, defenestrating the whole argument-in-favor. This completely breaks down in NixOS, too, where your package would get rebuilt from source as inputs changed.

load more comments (5 replies)