2005: The short life and hard times of a Linux virus https://web.archive.org/web/20140925152325/http://librenix.c...
...although market share certainly also plays a part.
Why GNU/Linux Viruses Are Fairly Uncommon
51–60 of 117 posts
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#52I've always sort of suspected there might be a 'don't shit where you eat' component to it. If you're just being a dick by screwing with people for fun, not profit, then maybe you screw with the windows users instead of your fellow linux users. Maybe that's giving them too much credit though.
Most malware code I've seen is terribly written and barely works. Hobbyist malware programmers use Windows and write for Windows for the simple reason that it's all they know. Some skiddies use Kali Linux but only because they managed to follow step-by-step instructions on YouTube without which they're lost.
Maybe if it's 'good' you don't see it? Like we only hear about the criminals that get caught...
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#53Re: Why GNU/Linux Viruses Are Fairly Uncommon
#54Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work. Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential m…
The person best positioned to lock down a program is the developer. Only they know when and how certain resources need to be accessed, and only they are positioned to refactor the source code to maximize the cost+benefit of stricter security policies. But solutions like selinux, apparmor, and tomoyo are built on the premise that it's the user, administrator, or packager best positioned. But this is a false premise. T…
Claiming the developer is in the best position to lock down there own programs is obviously making the assumption that the developer can be trusted. It would be much easier to audit a single file declaring all of the permissions a program has been granted than it would be to audit the entire source code of the program itself. I think it would be a great idea to integrate MAC more widely in package distribution systems.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#55Except that now everybody insists that you should be using package managers like apt and yum instead.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#56Earlier quoted context omitted.
> the [Debian] Release Team recently announced that Debian will no longer allow binaries built and uploaded by maintainers on their own machines to be part of the upcoming release. https://reproducible-builds.org/reports/2019-07/
This plus reproducible builds will go a long ways toward preventing it.
I would be careful about claiming built artifacts play much role in the visibility of repository-delivered malware. Consider "reflections on trusting trust" for attacks on reproducible builds, and also that all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted over the last year or so.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#57On a more serious note, I'm surprised there hasn't been much discussion about potential malware in official Linux package repositories vs. developer-centric source repositories like npm, rubygems, crates.io, etc. One would hope that the bar is higher with strict maintainership rules, but there are a zillion packages, and you can't vet them all. Also, practically everyone installs binary packages, so until we have ful…
This is a flaw with the repository model for software distribution: it confers the authority of the OS developers to packages not scrutinized to the same degree. Users' metal models of trustworthiness don't track very well the actual scrutiny software is subjected to. This might be a problem with any distribution system.
I think you're overestimating the rigor of other software delivery channels. Consider for instance that the biggest Windows SSH client (PuTTY) was delivered over http from a super sketchy looking website until very recently. Now it's the same super sketchy looking website, but with a green lock!
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#58Except that now everybody insists that you should be using package managers like apt and yum instead.
Who are these people? In the Python community, no project ever used yum/apt. Their versions of basically every package (where they even have it) are hilariously out of date with what you should use. They are frequently missing major security fixes, in addition to the usual functionality ones. My understanding is that this applies to most other languages as well.
To say nothing of docker base images and popular docker containers...
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#59Earlier quoted context omitted.
The person best positioned to lock down a program is the developer. Only they know when and how certain resources need to be accessed, and only they are positioned to refactor the source code to maximize the cost+benefit of stricter security policies. But solutions like selinux, apparmor, and tomoyo are built on the premise that it's the user, administrator, or packager best positioned. But this is a false premise. T…
Claiming the developer is in the best position to lock down there own programs is obviously making the assumption that the developer can be trusted. It would be much easier to audit a single file declaring all of the permissions a program has been granted than it would be to audit the entire source code of the program itself. I think it would be a great idea to integrate MAC more widely in package distribution system…
> It would be much easier to audit a single file declaring all of the permissions a program has been granted than it would be to audit the entire source code of the program itself
The problem is that it's much more difficult to write software that way, which is why few people do it. And it doesn't actually solve the problem of trust because it's exceptionally difficult to prove that those rules capture and constrain the most security-relevant aspects of the program, so you're back at square one in terms of trusting the developer and their skill.
Your argument makes the most sense if security were simply a matter of enumerating filesystem and syscall access. But it's rarely that easy. Usually you need certain kinds of access at various stages of the programs, or the types of access required are a function of the inputs to the program--e.g. the files specified on the command-line or the configuration file. Handling these requirements in the most appropriate ways tends to devolve to a matter of writing ad hoc code in the context of the peculiarities of the program architecture. Declarative solutions divorced from the structure of the code don't work well. What's most important are the time, place, and manner of constraining particular privileges, as opposed to merely identifying all the privileges and switching from "insecure" to "secure" at a single point in the application.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#60Earlier quoted context omitted.
I think the real answer is that relatively few people use GNU/Linux
Yea, probably 1% or less of desktop users. However, I bet those targets would be extremely high value (dev environments, server access). I am sure advanced groups heavily invest in gaining access to servers.
The thing there is you almost never need external tooling post-exploitation on Linux; it ships with most of the tools you could want. Add on that nobody seems to be able to harden web servers or SSH, and why would you need "viruses" in a targeted attack? Hack naked, and there's no hash to find.