Look, if the title is “why GNU/Linux viruses are fairly uncommon”, that’s fair game as a topic. In fact, you should expect that most of the discussion will be about that, rather than the self-deprecatory joke answer. Certainly it was last time: https://news.ycombinator.com/item?id=20680291.
(Also, my own observation is that it’s regularly far more amusing to take jokes seriously, ignore sarcasm, and otherwise wrest humour.)
I'm not really sure how a virus that can infect a server wouldn't also target linux desktop unless it's targeting SSH or Ampache or something. It would still have a chance at hitting poorly configured developer machines, and yet people barely experience them
In Step 5, my check resulted in NSF_BOUNCE. I was eventually able to replenish, but then wound up receiving an 'ACH_DELAY = 3-5 biz days' message. I apparently have to wait before evilmalware is available on my system.
I finally got past step 3 and 4 with a CHROOT where I manually built all dependencies, skipped the tests after reading your comment, went to go straight to the make install but my distro's got a non-standard directory layout and that failed.
I'm over this. Too much effort. I'm just going to install windows and click dodgy popup ads and any ok buttons that appear after.
I tried that, now my system's totally messed up. The spouse package was fine, but the child one was only available in 32-bits so suddenly my system was full of 32 bit libraries, my x64 libraries were all autoremoved, I lost half the apps on my system.
Now i'm just stuck here with this spouse and child on my computer, can't do anything fun any more. Lost all my games and it turns out the child is a daemon that runs in the background that sleeps and wakes at the most inconvenient times and now every time I try to run
For the ladies or non-binaries on the boards, they have an even easier set of commands, 'man find' or depending on distro 'man search' and 'man locate'. There's also additional tools with 'man configure' and 'man make'. It is important to remember to wear a bra on your head, and do NOT forget to attach the leads to the doll or you wind up with an MX missle in our living room.
This specific joke worked better in 00s when GLIBC compatibility issues were far more of a hassle than today.
But the joke still rings true today: not necessarily with GLIBC anymore... but maybe systemd vs initsystem, or XLib vs Wayland, and other such "non-backwards compatible changes" that seem to occur in the Linux world more often.
Is there any explanation for why backwards compatibility breaking changes are so common in the Linux world despite the fact that linux itself does such a good job avoiding it?
Are they really especially common in the Linux world?
UX: Windows 7 -> Windows 8 -> Windows 10 had some pretty drastic changes, even if a big part of Windows 10 was a climbdown. Have you followed the skeumorphic -> flat -> 3d again or Gingerbread to Holo to Material Design guidelines?
Dev facing: How have your migrations to WKWebView, notarised builds, M1, the Mac App Store, away from kexts, etc. been? Did you get onboard for WinRT and UWP?
You could argue in the Windows case you didn't _have_ to follow these trends, but you also didn't have to on Linux. Pidgin still works much the same as it did a decade ago. Thunderbird is still here and fundamentally the same as when I started using it as a literal child. You can still install MATE and XFCE and have pretty much the same workflow for desktop linux you had 20 years ago on Gnome 1, except with much much better chance of arbitrary hardware/software X working.
In the Apple case, you have to follow their guidelines in a much sooner period.
As code ages, people lose interest in maintaining. When you begin coding an application, you're usually adding features and that's fun, but as time passes and the software reaches its goal, you're left with finding and fixing bugs. That's no fun. Microsoft manages to do so because there's a money incentive for its employees, while free software has no such equivalent. That's why we see things like completely dropping X and writing Wayland from scratch: it's more fun and quicker for developer. Sucks to be us on the receiving end, though.
I believe until this kind of thinking shifts, there's not gonna be mass adoption of GNU/Linux systems. People expect software to work and keep working 10 years down the road. The current state of the FOSS ecosystem is full of bitrot and rewrites, with zero incentive for developers to maintain code. Beats the hell out of me why there isn't a distro that allows you to give money to patrons of the packages you use. It's a real no-brainer.
I could be wrong about this, but I think it mostly just comes down to the maintainers of libraries and software packages.
If you've got a less used or less known software package and an upstream library dev makes a breaking change, you've got a choice, stick with the old version or update your code to work with the new version.
As time passes, new projects are started on the new version, the new version gets picked up by distro maintainers, old version is slowly phased out as more devs use the newer version. Eventually, maintaining old version and new version in package repos is too much effort to be worth it, old version gets removed, any software stuck on the old version is now broken on that distro without a bunch of workarounds.
And essentially, this is happening all the time with most libraries and such.
I'd say the most likely reason would be the modularity of the user land. Namely it makes the adoption of such backwards incompatible changes much easier.
Anyone can make some new piece of software to do something in a new way(ex. init systems). And there will be people who want to use it and don't want to use it. Most of the time distors (and forks) will arise that do it the new way and people who want that will pick those distros. This is really common in the init-systems vs systemd debate.
Might be a GNU ploy, but the more likely explanation is that compatibility requires extra work and effort. Just think about how often libpng broke compatibility. Some libraries are so bad about this (like libpng) that even rolling release distros like Arch have to package multiple versions.
No one is willing to put in the effort on Linux to make deployment of software easier. And from the PoV of the distros there is nothing to fix anyway. Windows has invented and largely fixed the DLL hell. Linux only managed to copy the problem.
It’s great that the kernel is taking it so seriously, but everything else doesn’t care and constantly breaks compat.
Linux has not copied the DLL hell problem. If you think that, you don't understand what DLL hell was.
I assume that by deployment of software, you mean "someone other a distro maintainer building and packaging software". That's no harder on Linux than it is on Windows or macOS (*) , it's just that Linux users have the additional option to get software from their distro too.
macOS: you put everything your app needs into ... well, a folder (with some required filenames and organization)
windows: you put everything your app needs into ... a folder (with some required filenames and organization)
linux: you put everything you app needs into ... a folder. Full integration into "the desktop" needs a few additional steps, easily carried out by an install process.
What is missing on Linux is a nice, clean, commonplace way for users to actually carry out the installation process for 3rd party (ISV) software that isn't packaged using the distro packaging system.
(*) other than issues with certain, ahem, toolkits that make it hard or impossible to statically link against them (and note: these are typically cross-platform toolkits, ironically).
> and other such "non-backwards compatible changes" that seem to occur in the Linux world more often.
The term DLL hell was termed in the Windows world for a reason.
If you stay with what the package manager offers for a well-maintained distro I don't think the user ever sees incompatibility issues in Linux. The distro maintainers (or if you build something custom) sees those issues, but often enough a build time, not at runtime.
How far do people get sticking to first-party packages? I inevitably end up, like, wanting to have videogames or newer development tools or something. I guess developers might be outliers, but even my work laptop ships with distro-managed browser versions that the work-managed SSO login form rejects as too old, so pretty much everybody has a non-distro-packaged browser install.
I don't know any distro that doesn't update browser packages in stable releases. Fedora, Ubuntu, Arch (ok, Arch is rolling release but still) and NixOS at least offer the lastest versions of Firefox and Chromium on its repository. Debian too, but I think they package Firefox ESR instead of Firefox release.
Yeah, it's an ESR, but the SSO thing specifically wants a recent version and not ESR. Not pretending that's a good decision, but I still have to go along.
Organizations just standardize on one thing. CentOS (but not anymore I guess v.v) or RHEL or Ubuntu or Debian etc. Pick an LTS and then install it on all the work-provided hardware and just make sure everything works for your org.
For individuals, (and by that I mean me and like a few of my friends who run GNU+Linux) it's something like:
1. Docker
2. Use Arch Linux
Personally, my setup is:
Machine I use as a PC run Arch so everything is just latest vanilla upstream.
My homelab is ostensibly Ubuntu LTS, but I run docker on almost every host, and have a Proxmox host too, so the Ubuntu layer directly on the machine only really gets used for running ping, dig and nmap (and docker of course).
If you use a rolling release distro, stuff stays pretty up-to-date. For games, there are usually free software titles packaged. Minetest, Xonotic, StepMania, Cataclysm: Dark Days Ahead, Dungeon Crawl Stone Soup, Nethack, Red Eclipse, Super Tux Kart...
There are many solutions to the same problem.
==================================================
A rolling release distro suffers from that problem vastly less than a rolling release since you will usually have current versions of most tools if your distro has enough people to maintain it. See gentoo, funtoo, arch, manjaro, void.
Making it easy to produce alternative package repos goes a long way towards having people actually make them. See overlays in gentoo/funtoo and ppas in ubuntu and ubuntu based distros like mint. This is especially important in ubuntu which is not rolling and can be different degrees of out of date especially if you use the long term support versions.
Making it easy to produce a package goes a long way towards it being easy to make one even if its only used by yourself. Arch/Manjaro Funtoo/Gentoo packages are both very easy.
Gentoo/Funtoo use flags make it easy to build an alternative version of a package eliminating the need to build it because the distro maintainer didn't enable the feature you need.
Arch's AUR makes it easy to add a package that can also be produced from source and updated like any other package via aur helper. Can also have alternative builds of the same package.
Of many distros I have used over time I would say that on Arch and Funtoo I didn't have to build anything manually but I did rely on the AUR and overlays + made a package for funtoo which was very very easy.
On mint and ubuntu I ended up with about a million ppas + building some things.
On net I'd say that rolling release + a system where users can trivially create their own packages on something like the AUR is the most versatile while still being accessible. Funtoo was even more flexible but substantially more complicated.
However for various reasons I'm using Void now and have only 2 manually build things. Gargoyle because its not in the repo and I hadn't figured out how to make a package and mpv with a sndio partch.
I have have worked over 10 years Linux only. I have never needed to install a different browser.
Sometimes I needed Skype telcos with some customers, recently I needed Zoom for some training. Both have .deb packages that worked. Occasionally I needed some developer tools, but they were generally Linux-friendly and did not cause any trouble.
Yes, I am nowadays selective with what employer I would join. If their IT department is Windows-focussed they are not for me. That greatly limits choice, but reduces daily frustration efficiently.
If you care about running bleeding edge software, then you're probably running a rolling release distribution where the software in repositories is only out of date for a few hours or days.
Assuming what you want is in there and someone is maintaining it, which is a big if you're doing anything even a little bit unusual.
Linux Desktop seems to believe the world must be bifurcated between "stable, predictable system" and "absolute bleeding edge software". What if I want old trusted versions of some things and bleeding edge of other software?
Isn’t it backwards now though? I rarely experience any library issues in Windows simply because there are nearly no shared libraries. For a desktop system that’s what I want. There are zero times on a desktop that I want to upgrade a shared package used by multiple apps, eg for security fixes.
It’s not worth the hassle. Isolated apps wins every time. Now Windows apps even ship their runtimes bundled (.NET core, C++ runtimes). This is a good thing.
Well, it may be a joke but the number of times I've downloaded some source code, hit ./configure, make, and then sudo make install on my linux box without checking any of it is also a joke....
As the saying goes, viruses on Linux are hard to get right because you need to make assumptions about API/ABIs, libraries, required dependencies, etc. which is never assured across-the-board.
Oh wait... Good desktop software needs all that too...
That would be a really bad virus that tries to depend on GNOME/GTK or some other library.
Maybe you are thinking at those terrible web based viruses where an Windows XP themed popup appears that tells you that you need to download and run something to fix your computer. So it is harder for those guys to detect the correct theme to use for their popup to trick the user.
As the saying goes, viruses on Linux are hard to get right because you need to make assumptions about API/ABIs
The Linux system call interface is stable. Or if you want to go up one level of abstraction, glibc has great backwards compatibility (using versioned symbols).
GNU/Linux viruses are fairly uncommon, because (virtually) no one uses Linux on the desktop. So, it is much harder to spread.
(Disclaimer: not a bashing attempt, I use Linux on the desktop.)
>glibc has great backwards compatibility (using versioned symbols).
As long as the virus or other software dev can restrain themselves from using the latest added features to glibc and c++??. Usually they can't so compiling something written with today's libs on a distro from 5 years is infeasible.
It's fairy easy to statically link everything into malicious software, as the imperative of malware is obviously neither to respect the user's wishes, nor to protect itself against vulnerabilities that might compromise the user.
The problem is that the word “virus” is not of any technical significance. The way I see it there are two important classes of malicious software:
1) The class that relies on being executed normally by the user, but then does things contrary to what the user expected it to.
2) The class that actually exploits design oversights to be able to run with privileges, or run at all, when it was not intended to by the user.
The latter class is obviously of a significantly larger concern.
“GNU/Linux” is also a social buzzword bereft of any technical meaning. Nothing exists that deserves to be so grouped together under “GNU/Linux” for any technical reasons, and the exploitations that class 2 exploits often have nothing to do with it.
There recently was such an exploit that allowed malicious code to be executed ex nihilō. More specifically, it relied on an indexing dæmon that ran in the background and indexed media files, by creating a specifically crafted malformed image file, it could trick this dæmon into executing arbitrary code, apparently even as root as the dæmon ran as root and was shared between all users as I read it.
Such exploits are not a “GNU/Linux” issue; they are an issue of whatever system has this dæmon both installed and running. Apparently Fedora had, but my system does not.
The majority of such escalations these days seem to have little to do with either GNU or Linux, and mostly seemed to exploit “Freedesktop”, which is known to favor copying certain design sensibilities from Windows and with it the kind of escalative holes that such design sensibilities often bring with them, such as the aforementioned.
> Oh wait... Good desktop software needs all that too...
Are you saying it's not possible to have good desktop software on Linux? Users of JetBrains' IntelliJ IDEA and users of, say, Blender, are going to disagree (for example).
As a corollary, there was a very old joke that a Microsoft Windows virus would require that the user "Please insert virus disk 2" to complete the installation.
If this were the actual explanation, don't we expect it to have substantially changed with the rise of apt/yum/snap/appimage/flatpak or any other technology which provides the virus with an end-around these steps?
i have a bunch of viruses which i collected last year when i was under a 9 month internet blackout, propagated only in windows machines without internet access. at one point, i set up a "xp vm" on my kde neon, loaded an infected file and spend a good day figuring out where it was. turns out this particular virus saves a copy of itself in user/appdata folder in C, then opens a process with that name, "usually newfolder" and once a removable drive was detected, it would 1, move all contents into a " " folder (yes. a folder named as a single space, then put that folder as system hidden folder so that it gets hidden (and only visible if going into folder settings, show system files)
then create new shortcuts to all old files which did 2 things, one, symlink style open that particular file and more importantly, copy the virus executable to the current system if not already present.
it was a fun exercise. i had told a colleague, "either this virus survives today or i will".
oh, there was one downside to another strain of this virus. if i deleted the autorun file, it would go ahead and delete the entire removable drive data. that was PITA
the only reason this virus and similar others propagated so wildly during that time was because there was no internet and windows as far as i know, "expects" 24x7 internet connectivity
The only way i am aware of to assure no unwanted program is running(virus or not) is using the top "ps -e" command to monitor cpu activity. What if the virus modifies the ps command to hide the malicious process in the output ? How should this situation be handled ?
69 comments
[ 2.6 ms ] story [ 142 ms ] thread...and the 0 days are saved for valuable servers and embedded devices
Just thought this was a Stallman writeup. To be fair, the titles are usually similar.
(Also, my own observation is that it’s regularly far more amusing to take jokes seriously, ignore sarcasm, and otherwise wrest humour.)
edit: lol at the article
I'm over this. Too much effort. I'm just going to install windows and click dodgy popup ads and any ok buttons that appear after.
alternatively on debian-based systems using the package manager:
choose one, then: Note that this may add other required or recommended dependencies.Now i'm just stuck here with this spouse and child on my computer, can't do anything fun any more. Lost all my games and it turns out the child is a daemon that runs in the background that sleeps and wakes at the most inconvenient times and now every time I try to run
spouse -s
It just prints
'I'm tired not tonight.'
But the joke still rings true today: not necessarily with GLIBC anymore... but maybe systemd vs initsystem, or XLib vs Wayland, and other such "non-backwards compatible changes" that seem to occur in the Linux world more often.
UX: Windows 7 -> Windows 8 -> Windows 10 had some pretty drastic changes, even if a big part of Windows 10 was a climbdown. Have you followed the skeumorphic -> flat -> 3d again or Gingerbread to Holo to Material Design guidelines?
Dev facing: How have your migrations to WKWebView, notarised builds, M1, the Mac App Store, away from kexts, etc. been? Did you get onboard for WinRT and UWP?
You could argue in the Windows case you didn't _have_ to follow these trends, but you also didn't have to on Linux. Pidgin still works much the same as it did a decade ago. Thunderbird is still here and fundamentally the same as when I started using it as a literal child. You can still install MATE and XFCE and have pretty much the same workflow for desktop linux you had 20 years ago on Gnome 1, except with much much better chance of arbitrary hardware/software X working.
In the Apple case, you have to follow their guidelines in a much sooner period.
I believe until this kind of thinking shifts, there's not gonna be mass adoption of GNU/Linux systems. People expect software to work and keep working 10 years down the road. The current state of the FOSS ecosystem is full of bitrot and rewrites, with zero incentive for developers to maintain code. Beats the hell out of me why there isn't a distro that allows you to give money to patrons of the packages you use. It's a real no-brainer.
If you've got a less used or less known software package and an upstream library dev makes a breaking change, you've got a choice, stick with the old version or update your code to work with the new version.
As time passes, new projects are started on the new version, the new version gets picked up by distro maintainers, old version is slowly phased out as more devs use the newer version. Eventually, maintaining old version and new version in package repos is too much effort to be worth it, old version gets removed, any software stuck on the old version is now broken on that distro without a bunch of workarounds.
And essentially, this is happening all the time with most libraries and such.
Anyone can make some new piece of software to do something in a new way(ex. init systems). And there will be people who want to use it and don't want to use it. Most of the time distors (and forks) will arise that do it the new way and people who want that will pick those distros. This is really common in the init-systems vs systemd debate.
No one is willing to put in the effort on Linux to make deployment of software easier. And from the PoV of the distros there is nothing to fix anyway. Windows has invented and largely fixed the DLL hell. Linux only managed to copy the problem.
It’s great that the kernel is taking it so seriously, but everything else doesn’t care and constantly breaks compat.
I assume that by deployment of software, you mean "someone other a distro maintainer building and packaging software". That's no harder on Linux than it is on Windows or macOS (*) , it's just that Linux users have the additional option to get software from their distro too.
macOS: you put everything your app needs into ... well, a folder (with some required filenames and organization)
windows: you put everything your app needs into ... a folder (with some required filenames and organization)
linux: you put everything you app needs into ... a folder. Full integration into "the desktop" needs a few additional steps, easily carried out by an install process.
What is missing on Linux is a nice, clean, commonplace way for users to actually carry out the installation process for 3rd party (ISV) software that isn't packaged using the distro packaging system.
(*) other than issues with certain, ahem, toolkits that make it hard or impossible to statically link against them (and note: these are typically cross-platform toolkits, ironically).
..but on second thought, hat's actually selinux doing its job if the executable is a real virus.
The term DLL hell was termed in the Windows world for a reason.
If you stay with what the package manager offers for a well-maintained distro I don't think the user ever sees incompatibility issues in Linux. The distro maintainers (or if you build something custom) sees those issues, but often enough a build time, not at runtime.
Organizations just standardize on one thing. CentOS (but not anymore I guess v.v) or RHEL or Ubuntu or Debian etc. Pick an LTS and then install it on all the work-provided hardware and just make sure everything works for your org.
For individuals, (and by that I mean me and like a few of my friends who run GNU+Linux) it's something like:
1. Docker 2. Use Arch Linux
Personally, my setup is:
Machine I use as a PC run Arch so everything is just latest vanilla upstream.
My homelab is ostensibly Ubuntu LTS, but I run docker on almost every host, and have a Proxmox host too, so the Ubuntu layer directly on the machine only really gets used for running ping, dig and nmap (and docker of course).
Making it easy to produce alternative package repos goes a long way towards having people actually make them. See overlays in gentoo/funtoo and ppas in ubuntu and ubuntu based distros like mint. This is especially important in ubuntu which is not rolling and can be different degrees of out of date especially if you use the long term support versions.
Making it easy to produce a package goes a long way towards it being easy to make one even if its only used by yourself. Arch/Manjaro Funtoo/Gentoo packages are both very easy.
Gentoo/Funtoo use flags make it easy to build an alternative version of a package eliminating the need to build it because the distro maintainer didn't enable the feature you need.
Arch's AUR makes it easy to add a package that can also be produced from source and updated like any other package via aur helper. Can also have alternative builds of the same package.
Of many distros I have used over time I would say that on Arch and Funtoo I didn't have to build anything manually but I did rely on the AUR and overlays + made a package for funtoo which was very very easy.
On mint and ubuntu I ended up with about a million ppas + building some things.
On net I'd say that rolling release + a system where users can trivially create their own packages on something like the AUR is the most versatile while still being accessible. Funtoo was even more flexible but substantially more complicated.
However for various reasons I'm using Void now and have only 2 manually build things. Gargoyle because its not in the repo and I hadn't figured out how to make a package and mpv with a sndio partch.
Sometimes I needed Skype telcos with some customers, recently I needed Zoom for some training. Both have .deb packages that worked. Occasionally I needed some developer tools, but they were generally Linux-friendly and did not cause any trouble.
Yes, I am nowadays selective with what employer I would join. If their IT department is Windows-focussed they are not for me. That greatly limits choice, but reduces daily frustration efficiently.
Your choice of software will be limited and almost certainly out of date.
Linux Desktop seems to believe the world must be bifurcated between "stable, predictable system" and "absolute bleeding edge software". What if I want old trusted versions of some things and bleeding edge of other software?
It’s not worth the hassle. Isolated apps wins every time. Now Windows apps even ship their runtimes bundled (.NET core, C++ runtimes). This is a good thing.
I'm trying to compile this virus but it says it didn't find any makefile? What am I missing?
./configure --prefix=`pwd`
:
:
Oh wait... Good desktop software needs all that too...
Maybe you are thinking at those terrible web based viruses where an Windows XP themed popup appears that tells you that you need to download and run something to fix your computer. So it is harder for those guys to detect the correct theme to use for their popup to trick the user.
The Linux system call interface is stable. Or if you want to go up one level of abstraction, glibc has great backwards compatibility (using versioned symbols).
GNU/Linux viruses are fairly uncommon, because (virtually) no one uses Linux on the desktop. So, it is much harder to spread.
(Disclaimer: not a bashing attempt, I use Linux on the desktop.)
As long as the virus or other software dev can restrain themselves from using the latest added features to glibc and c++??. Usually they can't so compiling something written with today's libs on a distro from 5 years is infeasible.
The problem is that the word “virus” is not of any technical significance. The way I see it there are two important classes of malicious software:
1) The class that relies on being executed normally by the user, but then does things contrary to what the user expected it to.
2) The class that actually exploits design oversights to be able to run with privileges, or run at all, when it was not intended to by the user.
The latter class is obviously of a significantly larger concern.
“GNU/Linux” is also a social buzzword bereft of any technical meaning. Nothing exists that deserves to be so grouped together under “GNU/Linux” for any technical reasons, and the exploitations that class 2 exploits often have nothing to do with it.
There recently was such an exploit that allowed malicious code to be executed ex nihilō. More specifically, it relied on an indexing dæmon that ran in the background and indexed media files, by creating a specifically crafted malformed image file, it could trick this dæmon into executing arbitrary code, apparently even as root as the dæmon ran as root and was shared between all users as I read it.
Such exploits are not a “GNU/Linux” issue; they are an issue of whatever system has this dæmon both installed and running. Apparently Fedora had, but my system does not.
The majority of such escalations these days seem to have little to do with either GNU or Linux, and mostly seemed to exploit “Freedesktop”, which is known to favor copying certain design sensibilities from Windows and with it the kind of escalative holes that such design sensibilities often bring with them, such as the aforementioned.
Are you saying it's not possible to have good desktop software on Linux? Users of JetBrains' IntelliJ IDEA and users of, say, Blender, are going to disagree (for example).
it was a fun exercise. i had told a colleague, "either this virus survives today or i will".
oh, there was one downside to another strain of this virus. if i deleted the autorun file, it would go ahead and delete the entire removable drive data. that was PITA
the only reason this virus and similar others propagated so wildly during that time was because there was no internet and windows as far as i know, "expects" 24x7 internet connectivity