93
Linux Antivirus? (lemmy.wtf)
submitted 11 months ago by to c/linux@lemmy.world
79 comments fedilink hide all child comments
 

I'm about to install bazzite on my wife's older (2017) Windows 10 machine, and I've been going over how to recreate everything she currently has. Most programs (even proprietary ones) are not an issue, but I'm not finding much in the antivirus department.

I never even thought to install one on my Linux machine (also on bazzite, but I have used other distros in the past). So although I am no stranger to Linux, this issue blindsided me.

I know clamav exists, and I'm educating myself on how to use it, but a GUI would be nice for the wife. She's not afraid of the terminal, but she likes the convenience of GUI programs.

Any suggestions? What do you use? Or is it just generally accepted that one should be careful and keep things up-to-date and that's enough?

you are viewing a single comment's thread
view the rest of the comments
[–] 14 points 11 months ago (16 children)

I think there's a few aspects to this whole subject.

First of all for a long time people have thought Linux not to be the target of malware. I would say that it has been a target and it has been for decades. I recall in the late 90s a Linux server at work was attacked, had a rootkit, IRC trojan and attack kit installed by script kiddies in Brazil. I think the nearest you can say is that desktop users aren't usually a target, which is mostly true. But with the share of desktop installs hitting a high recently we should expect that to change.

Second I think most windows antivirus products (including the built in one) are doing some active useful things. Most of these are not relevant on Linux (we generally don't run setup.exe from random websites). However! Here's where things get interesting. The rise of flatpak and other containerised applications. These I would say are very similar to setup.exe, and would make it trivial to embed malware into such a file. A Linux virus scanner could be checking these. Also we've seen direct attacks on distro repositories lately. I don't expect this to slow down. We are most certainly a target now.

Third, the other reason most Linux users don't use virus scanners is because they're usually technical people who would recognise (usually) something wrong and investigate/spot the malware. I would say two things are changing here. Simpler to install distros are bringing in less technical people to Linux and, the number of processes running on a machine doing effectively nothing in a desktop environment is way higher than it used to be. So technical people can be caught off guard. Also, a rootkit can hide all of these clues if done well.

So I would say there's a really good space to have a well made virus scanner/antivirus now. It is probably the right time for it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 16 child comments
    •
  • [–] 6 points 11 months ago* (3 children)

    Guarantee my fifteen year old would run a random curl with sudo if it purported to install Sims mods. And one might say, "then don't give her sudo," but you have no idea how often I'd have to run to the basement to type in a password onto her computer, if it's anything like Windows. (Haven't moved her to Linux yet, but it's coming.)

    We definitely cannot rely on the technical savvy of Linux users any more. At least, I can't.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 6 points 11 months ago (2 children)

    but you have no idea how often I’d have to run to the basement to type in a password onto her computer,

    For what it's worth: It's possible to configure sudo in a way that allows users to execute specific commands without having to grant full, unrestricted access. That's what sudo is for.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 11 months ago (11 children)

    we generally don’t run setup.exe from random websites

    We do run .deb/.rpm files from random websites though. And you mentioned flatpak too. Appimage is quite popular too, and afaik that doesn't have any built-in sandboxing at all.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 2 points 11 months ago (10 children)

    We do run .deb/.rpm files from random websites though.

    In general with Linux sites with deb/rpm/etc files would usually include hashes for the genuine versions etc. Not to say the actual author of these could be malicious.

    And you mentioned flatpak too. Appimage is quite popular too, and afaik that doesn't have any built-in sandboxing at all.

    Even with sandboxing, they generally need access to save files/load files etc from the host environment. Where are these connections defined? Could a malicious actor for example grant their malicious appimage/flatpak more access? Genuine questions, I've never looked into how these work.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 3 points 11 months ago*

    In general with Linux sites with deb/rpm/etc files would usually include hashes for the genuine versions etc. Not to say the actual author of these could be malicious.

    Imho, these hashes are hardly a security feature. If a malicious actor can control the file that you download, they likely can also control the hash.

    Even with sandboxing, they generally need access to save files/load files etc from the host environment. Where are these connections defined? Could a malicious actor for example grant their malicious appimage/flatpak more access? Genuine questions, I’ve never looked into how these work.

    Good question. I hope there's some form of security present, but I really don't know.

    But in the end, the most valuable stuff on a computer is user data anyway. Who needs root on a machine, if the attacker can also encrypt all your personal files?

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 11 months ago (8 children)

    AppImages have no sandboxing as you said. They also rely on the deprecated SUID-root binary FUSE2. AppImages are bad for security but they are convenient. A malicious AppImage could for example connect to org.freedesktop.secrets and access your keychain, or run a script that places a script called "sudo" in $HOME/.local/share/bin that is preferred over the real sudo and logs a password, or encrypt your files in a ransomware attack, or exfiltrate your session cookies from Firefox or Chromium browsers.

    Flatpaks on the other hand are sandboxed. IIRC Flatpaks can't access other Flaptak's data folders in $HOME/.var/app (maybe even if home access is given?), but if given access to the "home" permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission. Modern apps that are designed to work as Flatpaks can use the xdg-desktop-portal to access only specific files/dirs upon user request, but it is only temporary access to a file. All the ways a Flatpak can access the system are defined by its permissions, so by giving more/dangerous permissions (such as devices or full filesystem access) a malicious app can possibly escape the sandbox and access arbitrary permissions. The worst permission an app can have is access to session bus for org.freedesktop.Flatpak, which allows it to arbitrary permissions, host command execution, and access to Flatpak configuration.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 2 points 11 months ago*

    There is more to xdg-desktop-portal than I said, it is quite powerful.

    https://wiki.archlinux.org/title/XDG_Desktop_Portal

    https://flatpak.github.io/xdg-desktop-portal/docs/

    This Flatpak shows the power of portals on your system, while also requiring no permissions at all: https://flathub.org/en/apps/com.belmoussaoui.ashpd.demo

    Same with this one, but it requires arbitrary permissions: https://flathub.org/en/apps/xyz.tytanium.DoorKnocker

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 11 months ago (6 children)

    They also rely on the deprecated SUID-root binary FUSE2.

    There is no such thing as a suid fuse2, you are talking about suid fusermount, and libfuse2 which hasn't been true for 3 years the runtime is now static and doesn't depend on any libfuse (or any library) to work.

    And even back then it wasn't a hard dependency either, you could still run appimages by setting APPIMAGE_EXTRACT_AND_RUN=1 which makes them run without FUSE.

    The runtime still depends on a suid fusermount in PATH (it checks all the way to fusermount99 lol), however there is a much better runtime that does not FUSE to work at all since it can use mount namespaces instead.

    Meanwhile flatpak has a hard dependency on fusermount, it actually broke recently on ubuntu because they wanted to restrict access to fusermount.

    but if given access to the “home” permission they can read and write to anywhere else in the user home, so stealing session cookies from a browser or ransomware could still be possible given the right permission.

    web browsers (and electron apps) already have their own internal sandbox, which actually gets weakened by flatpak so it is actually not a good idea to be running those things with flatpak 1 2 3

    firefox recently finally got a fork server in linux, which means it is possible to at least get the zypack hack working with it, no idea if it has been implemented yet though.

    You also can sandbox appimages with bubblewrap, which is the very same sandbox flatpak uses, I wrote this tool used by AM for that.

    Apps will also have access to the portals, although I don't like this and looks like there is no easy way to disable access to portals other than disable all access to dbus which is bad.

    We already had an incident where someone thought there was a sandbox escape when it was just the app opening the portal xd

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 11 months ago (1 child)

    I had heard of AM, and I actually stumbled upon your tool before. Thank you for the tool. I wish AppImage was updated to include sandboxing by default.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 11 months ago*

    AppImage is just a format, nothing is stopping distros from adding a binfmt_misc rule that makes all appimages be sandboxed with any tool. (this also means you can set this up so that they get executed inside a flatpak env btw)

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 11 months ago (1 child)

    Yes, i understand that Flatpak weakens browser sandboxes, i was talking about the risk of a Flatpak which has access to user home and therefore could for example access $HOME/.firefox and steal session cookies.

    Also I based my assessment of use FUSE2 for normal AppImages on the security hardening used by Secureblue, mentioned here under the section "Filling known security holes"

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 11 months ago

    i was talking about the risk of a Flatpak which has access to user home and therefore could for example access $HOME/.firefox and steal session cookies.

    Okay that makes sense.

    Also I based my assessment of use FUSE2 for normal AppImages on the security hardening used by Secureblue, mentioned here under the section “Filling known security holes”

    Remove the unmaintained and suid-root fuse2 by default.

    kek they got it wrong. Also:

    Mitigate LD_PRELOAD attacks via ujust toggle-bash-environment-lockdown.

    Interesting, I wonder if they prevent executing the ld-linux.so as well.

    There is two ways to preload libraries without having to modify the binary, the first is using LD_PRELOAD, the second is less well known but you can run binaries by calling the dynamic linker first (internally this is actually how all dynamic binaries you execute work btw) and then use the --preload flag to load a library.

    That is instead of:

    LD_PRELOAD=./kek.so /path/to/bin

    you do:

    /lib64/ld-linux-x86-64.so.2 --preload ./kek.so /path/to/bin

    I'm going to take a wild guess and assume the second is still possible in secureblue 👀

  • permalink
  • fedilink
  • source
  • parent