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 don’t need an antivirus. Use common sense, as that is your best antivirus, period.
Long-time Linux user, have never run AV on my Linux machines.
A few years back, I was forced by compliance rules at work to install AV on a Linux server and started looking for solutions. I shopped around a bit and what I found was that even the commercial AV vendors who supported Linux had no more than 4 or 5 actual signatures to detect Linux malware, and they were all 5 or more years old.
Things may have changed since then, but this may be a good way to think about it… how much Linux malware can these tools actually detect?
Yes, Linux rootkits are a thing but if your AV doesn’t detect them, there’s no point running it.
I like to consider myself part of the exclusive and oh so elite club of linux users. everyone here saying that AV is not needed, because the best security is not to be stupid, is right. but is your grandma tech literate enough to not do stupid things on her computer? your teenage son?
as the linux user base grows, the platform becomes more interesting of a target. even for stupid attacks. and lets be honnest: lots of legitimate open source projects still use an install script to curl and pipe into the terminal as a suggested method to install. which is just horrible!
while an anti malware is a patch. it is the last line of defense after a stupid mistake. so it would be great to have an actual desktop AV for linux. eset used to sell one but it is long out of service.
i use clamAV. but i maintain it for the family, so it is not as simple as telling them exactly what to install and run with default configs.
anyway, for those interested: here are two videos of malware attacks against lunux in rather different fashions:
ClamAV is probably the way to go. While there are UIs available in various states of maintenance, it’s not really necessary. The way ClamAV works is that runs a scan on daemon (re)start then continually monitors the system from there. One of it’s best features is that you don’t really need to worry about it.
The best Linux antivirus is a healthy dose of
dontclickshit.bin.She’s not afraid of the terminal, but she likes the convenience of GUI programs.
Your wife appears to have the same preferences as I do. I don’t mind using the terminal (I usually have one open any time I’m using my laptop or PC), but some things are far simpler in a GUI.
Bahahahaha
An antivirus is mostly unnecessary when care is taken to not install or use untrusted software. If you install everything as a Flatpak (and modify some of the default permissions), you can avoid allowing software to gain much access to her computer.
While I think people suggesting Linux is immune to malware is stupid, for reasons such as it is “too secure” or “too niche” to be effected by malware, anti malware is like a bandaid to a gaping wound. If you have malware, it is already too late and you should first unplug the device from the network and any connected devices, backup any important data, and fresh reinstall by overwriting the infected install.
If you still think you need some way to defend against malware, use the VirusTotal website, or a native Flatpak called Lenspect, to upload and scan files (such as an executable binary). Lenspect requires no permissions other than network access, so it is safe and the only risk is if you input a file containing personal data it will be uploaded to VirusTotal.
Though to stress again, antivirus is a bandaid! The real solution is to be smart about what you install and only take stuff from trusted sources. Try to make sure everything is a Flatpak and avoid apps with excessive permissions, which weaken the security of the sandbox.
The “too niche” part is really weird to me. There’s an estimated 2 billion PCs in use right now. ~3% of that are running some form of Desktop Linux OS, so roughly 60 million.
Incidentally, that’s exactly the same number as the total number of Win95 licenses sold, and I can’t recall Win95 being “too niche” for malware. Quite the opposite.
Incidentally, that’s exactly the same number as the total number of Win95 licenses sold, and I can’t recall Win95 being “too niche” for malware. Quite the opposite.
In Win95 days, “always online” was simply not a thing for the average household. Getting on the Internet - if you even had a connection at all - was equivalent to making a phone call, in that you “called in” to do the thing you wanted to do, then “hung up” when you were done (yes, I know dial-up did almost exactly that in practice, but it’s still a good analogy).
Being “always online” is relatively recent, and anything online is going to be vulnerable to malware at some point in its life. Security patches need to keep up with that.
Exactly, and still the 60 million copies sold (of which maybe a quarter or so actually ever went online) was more than enough to make Win95 comically malware-infested.
I’d venture to say that close to every one of the 60 million copies of Desktop Linux OSes running goes online frequently, so there’s much more potential Linux targets than there ever were Win95 targets. That’s why I’m saying the “Linux is to niche to get malware” argument doesn’t really work.
OS security has gotten far better though, and there are a literal shitton more devices to target (like IOT crap) than someone’s slighty out-of-date Linux install.
But targets differ in value. Hack an IOT device and you can send some spam from it. Hack someone’s PC and you can ransomware their family pictures or steal their crypto crap.
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.
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.
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.
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.
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, andlibfuse2which 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=1which makes them run without FUSE.The runtime still depends on a suid
fusermountinPATH(it checks all the way tofusermount99lol), however there is a much better runtime that does not FUSE to work at all since it can use mount namespaces instead.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
I just realized your comment shows a Cromite AppImage? Where do you get that from?
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.
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)
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”
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.soas 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--preloadflag to load a library.That is instead of:
LD_PRELOAD=./kek.so /path/to/binyou do:
/lib64/ld-linux-x86-64.so.2 --preload ./kek.so /path/to/binI’m going to take a wild guess and assume the second is still possible in secureblue 👀
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?
To be more clear, antivirus in general are mostly scams because they are advertised to do much more than they are actually capable (especially proprietary ones that act as spyware such as Norton or Avast, which have been caught selling user data). Hash based antivirus solutions (such as ClamAV) aren’t effective either because they rely on “badness enumeration”, in which you try to determine all the bad samples (through a sample list(s)) and alert or delete them when detected. This isn’t a good solution because a threat actor only has to add for example a single whitespace character into the code and it will produce a wildly different hash (which has not been sampled before). Badness enumeration is shit way to deal with real problems, much better is an allowlist approach, such as a permission system where to minimize the access given and soften the security until the app runs.
TLDR: Antivirus bad at job of stopping malware, and sandboxed apps good for security of your device.
I’m not sure where you get the idea that antivirus is mostly a scam. Yes, there are some questionable vendors out there, but it doesn’t mean it’s a scam. I know antivirus has saved my ass a couple of times, at least when I was younger. Was I doing something stupid? Yes. Do we all do something stupid every once in a while? Also yes.
No, thanks.
I’ve been using it since about 1995 and the only uses for ClamAV I had were as a mail scanner for a mail server with Windows clients, and as a file scanner for a Samba server with Windows clients.
If you keep your system up to date, don’t install stuff from random sites, and don’t run as root all the time, you’ll be ok.
You might have issues trying to install clamav on Bazzite as it is an immutable distro
Antiviruses are rarely used, I wouldn’t install them on a newish distro for a non-tech user. It sounds like it may cause more issues than it will intercept
Kinda mirroring the other points here, if you only install from the distro’s repos then you’re all good.
But…
Better than AV (blocks known bad), you’re better off looking into things that only allow known good, like selinux, etc, which might be part of bazzite anyway? (I don’t use it, so unsure)
Linux is essentially immune because we don’t install random software off the internet and instead use centralized repositories of software
if you get a virus from that, antivirus won’t help you, but this essentially never happens.
Npm says what? Random appimages and flatpaks would like a word as well.
It’s true we generally need no antivirus - so far every demand to install one is rooted in stupidity, including policy built by stupidity - but we’re losing the struggle to not install random shit like idiots.
I believe Kaspersky has just released a commercial solution for desktop Linux. Kaspersky is a whole other can of worms, however seeing as they’re russians but that’s your call
Kaspersky isn’t there to protect us; just to fill a niche and create business for itself. Idiot nepo CTOs who don’t know better can be coerced to sign a fud-based invoice and then they make bank.
