Why GNU/Linux Viruses Are Fairly Uncommon(gnu.org)
gnu.org
Why GNU/Linux Viruses Are Fairly Uncommon
https://www.gnu.org/fun/jokes/evilmalware.html
116 comments
It's a joke, not analysis. Was hoping for the latter.
I think the real answer is that relatively few people use GNU/Linux
> I think the real answer is that relatively few people use GNU/Linux
95% of the server market, though. Which is a huge proportion of attack space. Why steal one sod's credit card numbers when you can steal 100s of them at the same time.
95% of the server market, though. Which is a huge proportion of attack space. Why steal one sod's credit card numbers when you can steal 100s of them at the same time.
When you attack a server, you don't use a virus, you use a phish or something else to gain access to it to do your dirty bidding.
What people call "viruses" usually refer only to attacks that work by getting people to execute random crap on their computer with their privileges. Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first place, so viruses target machines that are administered by end users (which would include home computers and smartphones!). The 95% market share for servers is irrelevant since viruses don't target servers in the first place.
What people call "viruses" usually refer only to attacks that work by getting people to execute random crap on their computer with their privileges. Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first place, so viruses target machines that are administered by end users (which would include home computers and smartphones!). The 95% market share for servers is irrelevant since viruses don't target servers in the first place.
It occurs to me that malicious code that scans WordPress etc. sites for vulnerabilities, installs itself, and sends spam and propagates itself does match the general shape of a virus (even to the point where pattern-matching antivirus would genuinely be effective against it). We just for whatever reason tend not to refer to it as a "WordPress virus," but rather e.g. a "reverse shell" or a "botnet."
I'd call that a worm, not a virus. The main distinction being that a worm propagates all by itself, while a virus requires some user action.
>Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first place
So this is why the 'curl | bash' idiom feels like an anti-pattern to me...
So this is why the 'curl | bash' idiom feels like an anti-pattern to me...
Right. Every time you read about a million credit cards being stolen it’s almost certainly from a Linux server, meanwhile the community is patting itself on the back because no viruses are targeting the tiny number of Linux desktop users...
That's about 95% of it. There are other things that give Linux a bit more of an edge in this space as well.
For example, every time I use Windows, it feels like every app is asking to run as administrator. Admittedly, I haven't used Windows for about a year, but in Linux, it's pretty rare that I ever do admin/sudo outside of the command line, and I only ever use it when I know what I'm doing. Obviously this isn't something that could not be fixed in Windows, and maybe it already has been.
For example, every time I use Windows, it feels like every app is asking to run as administrator. Admittedly, I haven't used Windows for about a year, but in Linux, it's pretty rare that I ever do admin/sudo outside of the command line, and I only ever use it when I know what I'm doing. Obviously this isn't something that could not be fixed in Windows, and maybe it already has been.
So far as I can tell, there are two kinds of (effectively) single-user systems, in which a malware infection is targeting a single person:
1. The kind where users are rarely asked to assume admin privileges and all the data a user has to protect is available without administrator access.
2. The kind where users are frequently asked to assume admin privileges and some of the data a user has to protect requires administrator access.
I don't believe Linux has any real edge here. I agree that 95% of the effect is due to Linux's paltry desktop user base; I'd guess than at least 4% is due simply to malware that targets Linux not being called "a virus".
1. The kind where users are rarely asked to assume admin privileges and all the data a user has to protect is available without administrator access.
2. The kind where users are frequently asked to assume admin privileges and some of the data a user has to protect requires administrator access.
I don't believe Linux has any real edge here. I agree that 95% of the effect is due to Linux's paltry desktop user base; I'd guess than at least 4% is due simply to malware that targets Linux not being called "a virus".
>Obviously this isn't something that could not be fixed in Windows, and maybe it already has been.
There is nothing even remotely obvious about that statement. If it was anything near possible it wouldn't an ongoing problem, unsolved for the last 12 years, since the introduction of UAC in Windows Vista.
Now I wouldn't say that Microsoft didn't progress. Far from it. Almost no one I knew kept Vista UAC enabled, as it was constant nag. Nowadays most folks can live with it, and corporations don't feel like they have to disable it and compromise their security to maintain their employees productive.
But it is still annoying way to often for it's own good. Many people are just automatically allowing everything, just like they press Yes or OK on every dialog box without ever reading it.
The reason it is so different on Windows is, in a nutshell, that Windows is a very different beast, and the way users and developers operate on it is not at all similar to what is done on Linux.
The integration of Windows applications with the OS API is something that, for better and for worse, doesn't exist on Linux. Be it the GUI, the Settings storage (registry vs config files) or any other part of the system.
There is nothing even remotely obvious about that statement. If it was anything near possible it wouldn't an ongoing problem, unsolved for the last 12 years, since the introduction of UAC in Windows Vista.
Now I wouldn't say that Microsoft didn't progress. Far from it. Almost no one I knew kept Vista UAC enabled, as it was constant nag. Nowadays most folks can live with it, and corporations don't feel like they have to disable it and compromise their security to maintain their employees productive.
But it is still annoying way to often for it's own good. Many people are just automatically allowing everything, just like they press Yes or OK on every dialog box without ever reading it.
The reason it is so different on Windows is, in a nutshell, that Windows is a very different beast, and the way users and developers operate on it is not at all similar to what is done on Linux.
The integration of Windows applications with the OS API is something that, for better and for worse, doesn't exist on Linux. Be it the GUI, the Settings storage (registry vs config files) or any other part of the system.
The main flaws with UAC is that you don't know what application is asking for it (This actually ties into a deeper problem which is, you don't know where application binaries reside, and applications are less predictable on Linux). Instead you have to correlate with what you've done recently, which might not align with the process that requested permission.
This is not true. Here, I took these screenshots for you where I copied an unsigned binary to a random location and forced a UAC prompt:
https://i.imgur.com/BSJlSAf.png
https://i.imgur.com/4ZVNsPN.png
I also did the same with a signed binary:
https://i.imgur.com/xpSiMMY.png
https://i.imgur.com/ACLydv0.png
https://i.imgur.com/BSJlSAf.png
https://i.imgur.com/4ZVNsPN.png
I also did the same with a signed binary:
https://i.imgur.com/xpSiMMY.png
https://i.imgur.com/ACLydv0.png
Interesting! Looks like my memory failed me, the one time I don't double check...
Not sure what you mean, this is not generally true - the dialog states the name of the process or the application requesting elevation, as you can see in a quick google pics search.
> and maybe it already has been.
Not completely, but I think it's mostly OK. I only see UAC prompts rarely, usually in one of these 3 cases.
1. Some software that I've written has good reasons to require elevation, I sometimes work on low level system software which uses weird WinAPI calls.
2. When installing software. The default location of installed programs, C:\Program Files, is read only unless running elevated. Probably done for extra security.
3. When using very old software, or bad quality ports from other OSes. UAC was introduced in Vista, some software which was written for WinXP or older versions requires elevation for no good reason.
Not completely, but I think it's mostly OK. I only see UAC prompts rarely, usually in one of these 3 cases.
1. Some software that I've written has good reasons to require elevation, I sometimes work on low level system software which uses weird WinAPI calls.
2. When installing software. The default location of installed programs, C:\Program Files, is read only unless running elevated. Probably done for extra security.
3. When using very old software, or bad quality ports from other OSes. UAC was introduced in Vista, some software which was written for WinXP or older versions requires elevation for no good reason.
lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.
How often do you see that in cases where someone wasn’t going to run the software anyway? I’m not sure how much of a risk this is adding now that HTTPS has become routine — is it really better to install a tarball, unaudited package on NPM/PyPI/etc.?
I've definitely seen plenty of `curl | bash` installations suggested before (and can honestly say that I've run some, despite knowing the risks), but _sudo_? Is that a thing that people actually do?
https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.
At the risk of appearing ignorant.. what exactly is the problem here? Do we trust the nodesource deb repo but we do not trust the bash script which is coming from the nodesource domain?
Deb packages have cryptographic signatures that can be verified to confirm it actually came from nodesource (or whoever)
If you get MITM'd (admittedly difficult with TLS) or the site got compromised (but not the build IX / developer's keyring) it would be possible to replace the script with a malicious one.
Also, you can detect the curl|bash installation method server-side and serve different content [1] on that basis, which is not possible with deb packages.
Finally, providing a curl|bash installation method implies that the developers either do not understand packaging, or don't care about it. This is fine e.g. if developers want to remain platform agnostic or just can't be bothered packaging, but if you develop a curl|bash installer you send the message "I want to distribute my software but don't care enough to do it properly / in a standards compliant way".
Also, and this is more subjective, most curl|bash installers I've seen make assumptions about their environments that do not necessarily hold in less common distributions - which makes you wonder why they don't just develop e.g. a deb if it only works reliably on Ubuntu and maybe Debian.
[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
If you get MITM'd (admittedly difficult with TLS) or the site got compromised (but not the build IX / developer's keyring) it would be possible to replace the script with a malicious one.
Also, you can detect the curl|bash installation method server-side and serve different content [1] on that basis, which is not possible with deb packages.
Finally, providing a curl|bash installation method implies that the developers either do not understand packaging, or don't care about it. This is fine e.g. if developers want to remain platform agnostic or just can't be bothered packaging, but if you develop a curl|bash installer you send the message "I want to distribute my software but don't care enough to do it properly / in a standards compliant way".
Also, and this is more subjective, most curl|bash installers I've seen make assumptions about their environments that do not necessarily hold in less common distributions - which makes you wonder why they don't just develop e.g. a deb if it only works reliably on Ubuntu and maybe Debian.
[1] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
> Deb packages have cryptographic signatures that can be verified to confirm it actually came from nodesource (or whoever)
And how do you get the GPG key to verify such signatures from third-parties? Usually via https from their website, no?
> Also, you can detect the curl|bash installation method server-side and serve different content
Yes, but you are supposed to trust people you get you packages from not to do it. And so and it should only make a difference if their servers are compromised and they sign packages with a key stored offline.
I think the latter is much less common then one would hope, with release processes in CI and such.
And how do you get the GPG key to verify such signatures from third-parties? Usually via https from their website, no?
> Also, you can detect the curl|bash installation method server-side and serve different content
Yes, but you are supposed to trust people you get you packages from not to do it. And so and it should only make a difference if their servers are compromised and they sign packages with a key stored offline.
I think the latter is much less common then one would hope, with release processes in CI and such.
This seems a little different to me than most `curl | bash` scripts, as it's trying to integrate with the system package manager. Not trying to imply the same security implications don't apply, but there's not really a way to integrate with them without requiring root, and it seems like the entire purpose of this is to integrate with the package manager, which gives you things like an easy way to get updates. (From looking further down the instructions, it looks like this is just setting up a PPA on debian-based distros; I'd personally just paste the config into a file myself, but realistically the security concerns are the same, since I think most package managers give the ability to execute custom code as part of the install process, and it'll be running as root when that code is executed)
Yeah...I don't think I've ever actually done that, but I could see some blog post saying to.
I think an annoying truth that us Linux-users don't like to admit is that another large part of what makes linux "more secure" is that only technical people bother using it. My parents are both smart people, but aren't programmers or anything, and as a result didn't like Linux when I tried to get them to use it; if they did use Ubuntu it's entirely possible that they'd figure out how to get a virus pretty quickly.
I think an annoying truth that us Linux-users don't like to admit is that another large part of what makes linux "more secure" is that only technical people bother using it. My parents are both smart people, but aren't programmers or anything, and as a result didn't like Linux when I tried to get them to use it; if they did use Ubuntu it's entirely possible that they'd figure out how to get a virus pretty quickly.
Relevant xkcd:
https://xkcd.com/1200/
https://xkcd.com/1200/
Without an effective application isolation a la iOS, itis exactly this.
Ah, XKCD. Truly a blessing to the modern world!
As if a virus really needed administrator access for anything...
Maybe to fuck up your machine... but if they want to snoop on your passwords, encrypt your files, mine bitcoin, participate in a DoS attack... they can do that without elevating
Maybe to fuck up your machine... but if they want to snoop on your passwords, encrypt your files, mine bitcoin, participate in a DoS attack... they can do that without elevating
[deleted]
You could even replace every command I run with a malware version simply by altering the $PATH in ~/.bashrc. If you manage to replace, say, apt-get with a malware version, you'll get admin permissions every time I run `sudo apt-get ...`.
If your sudo is configured correctly it will have an administrator defined PATH. However if you have sudo price to run apt-get, anything that could manipulate your rc files can just run sudo apt-get on its own. No need to trick you.
Unless it doesn't have your password, and sudo is configured to require auth to elevate. This is the STIG requirement for this exact reason
Edit: of course, it could just manipulate the path to include it's own evil sudo wrapper, but the chess match always sounds like this.
Edit: of course, it could just manipulate the path to include it's own evil sudo wrapper, but the chess match always sounds like this.
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.
Yeah, a lot of high-value secure systems run Linux and GNU. Web services, government systems, the vast majority (edit: it's now all) of the TOP500 supercomputers etc. I suspect at least part of it is that these systems get much more targeted attacks because of their high value, whereas viruses are to an extent un-targeted shotgun attacks. I suspect the economics of virus writing dictate that most of the effort is put towards the most popular platform, i.e. Windows.
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.
It's part that, but it's amplified by the fact that even in the tiny desktop GNU/Linux usage, there is no one GNU/Linux: a virus targetting a KDE, or GNOME, or XFCE, or—you get the point—something else, is targetting an even smaller part of that already small number of users.
Basically, the level of diversity in the ecosystem, while part of a reason for less widespread acceptance, also discourages any mainstream attacks.
Basically, the level of diversity in the ecosystem, while part of a reason for less widespread acceptance, also discourages any mainstream attacks.
Yes, but most of the important things are running on Linux, so it's not like it's not a potentially attractive target.
Smart phones and app stores are the real place to look. There are issues there.
what is the latter? not an analysis?
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.
...although market share certainly also plays a part.
Are we talking of just virus or other types of malware and rootkits?
Not sure what "uncommon" means but I think https://news.ycombinator.com/item?id=20682546 already documented that successful attacks are not rare.
Not sure what "uncommon" means but I think https://news.ycombinator.com/item?id=20682546 already documented that successful attacks are not rare.
Outlook doesn't run on *nix systems.
On the other hand,
"Unpatched KDE vulnerability disclosed on Twitter"
https://www.zdnet.com/article/unpatched-kde-vulnerability-di...
"Unpatched KDE vulnerability disclosed on Twitter"
https://www.zdnet.com/article/unpatched-kde-vulnerability-di...
Except 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...
To say nothing of docker base images and popular docker containers...
> are hilariously out of date
Well that's exactly the problem I run into with most packages (even outside of programming dependencies like Python libraries), but if ./configure, make, make install fails for any reason, the first google hit on the error message is "why are you trying to install this from source? Use the repos, that's what they're for"...
Well that's exactly the problem I run into with most packages (even outside of programming dependencies like Python libraries), but if ./configure, make, make install fails for any reason, the first google hit on the error message is "why are you trying to install this from source? Use the repos, that's what they're for"...
That doesn't match my experience at all; people usually realize that there are tons of reasons not to use the repo version. Perhaps you want a newer Python than the crusty old one that comes with 18.04. perhaps you want to test something that doesn't exist in the repos (the horror!). Docker and Elastic both recommend using their repos or building from source rather than using the geriatric versions in the Ubuntu repos.
I am the one saying that: for any Python packages in Ubuntu main, use them.
Why worry about tracking security issues of all your dependencies, when you can have that done by distribution's security team (Ubuntu pledges to patch all security bugs).
Why worry about tracking security issues of all your dependencies, when you can have that done by distribution's security team (Ubuntu pledges to patch all security bugs).
Are you a Python developer? How do you deal with the Ubuntu versions being different than the PyPI versions?
Are you a Python developer?[1] How do you deal with your project depending on an older version of a package with pip?
Basically, it's just like that (but instead of specifying your version in requires.txt/setup.py, you just install a package with a particular version). You've got an older library version that gets automatic security updates but does not break backwards compatibility (or it's a bug in the distro).
Ubuntu/Debian packages manage dependencies as well, so for anything you install from the "archive" (distribution's repository), you get compatible dependencies as well, so you can further reduce number of packages you need to pull in with pip. It's a bit of a bother if you've got two sources of dependencies, but if you can get free security updates and no backwards compatibility breakage for 5 years (Ubuntu LTS guarantee for packages in main), it's a small price to pay (though it certainly depends on the use case as well).
And luckily, Python + PyPI are _not_ JavaScript + NPM: with Python, you get a large standard library, and as you do not always need the latest and greatest of everything, you will not have hundreds, if not thousands of dependencies that you get with JS+NPM.
[1] Your first tongue-in-cheek question is, imho, totally inappropriate. If I misunderstood and it was not meant in a sarcastic way, I apologize for attempting to return the favour. :) Even then, your second question is totally valid and should have been sufficient if you honestly care.
Basically, it's just like that (but instead of specifying your version in requires.txt/setup.py, you just install a package with a particular version). You've got an older library version that gets automatic security updates but does not break backwards compatibility (or it's a bug in the distro).
Ubuntu/Debian packages manage dependencies as well, so for anything you install from the "archive" (distribution's repository), you get compatible dependencies as well, so you can further reduce number of packages you need to pull in with pip. It's a bit of a bother if you've got two sources of dependencies, but if you can get free security updates and no backwards compatibility breakage for 5 years (Ubuntu LTS guarantee for packages in main), it's a small price to pay (though it certainly depends on the use case as well).
And luckily, Python + PyPI are _not_ JavaScript + NPM: with Python, you get a large standard library, and as you do not always need the latest and greatest of everything, you will not have hundreds, if not thousands of dependencies that you get with JS+NPM.
[1] Your first tongue-in-cheek question is, imho, totally inappropriate. If I misunderstood and it was not meant in a sarcastic way, I apologize for attempting to return the favour. :) Even then, your second question is totally valid and should have been sufficient if you honestly care.
With requirements.txt, pyproject.toml/poetry, or pipenv depending on who the audience is, what conventions already exist in that community, and whether I need non-python dependencies as well. Friends don't let friends use setup.py (except sometimes you need to).
The Ubuntu versions of Flask, pymongo, and elastic are all out of date in the 18.04 (LTS) repos. Many are also out of date (although not as much) in all Canonical repos. Flask at least is missing security patches (bad) or the version number is misleading because they silently backported the fix (almost worse) in LTS. I've had backwards compatibility broken repeatedly by upgrading Canonical LTS versions of elastic and also numpy. It's actually happened so often that the set of tests in my CI that test with Ubuntu packages is named "what did they break this time" and can't fail the build.
I asked if you're a Python developer as it's my experience that sysadmins often think about this problem from the perspective of "use the repos, one less thing for me to manage" and developers think of it from the perspective of "I need the version of Flask that comes from PyPI, since that's what other devs will/have use(d)". I have very seldom encountered Python developers who use the distro-provided packages, and usually when I have it's because they didn't know about pip/PyPI. I apologise that the ambiguity caused offense, words are hard on computers :partyparrot:
The Ubuntu versions of Flask, pymongo, and elastic are all out of date in the 18.04 (LTS) repos. Many are also out of date (although not as much) in all Canonical repos. Flask at least is missing security patches (bad) or the version number is misleading because they silently backported the fix (almost worse) in LTS. I've had backwards compatibility broken repeatedly by upgrading Canonical LTS versions of elastic and also numpy. It's actually happened so often that the set of tests in my CI that test with Ubuntu packages is named "what did they break this time" and can't fail the build.
I asked if you're a Python developer as it's my experience that sysadmins often think about this problem from the perspective of "use the repos, one less thing for me to manage" and developers think of it from the perspective of "I need the version of Flask that comes from PyPI, since that's what other devs will/have use(d)". I have very seldom encountered Python developers who use the distro-provided packages, and usually when I have it's because they didn't know about pip/PyPI. I apologise that the ambiguity caused offense, words are hard on computers :partyparrot:
Ctrl+f "iot"
Ctrl+f "Mirai"
Oh, it's a joke. Got it.
Oh, it's a joke. Got it.
Leaving your door wide open isn't anyone's fault but your own. All the configurations and procedures for secure devices were there but manufactures couldn't bother.
On 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 fully reproducible builds, hiding malware in some obscure but heavily depended on package could actually be relatively easy.
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 fully reproducible builds, hiding malware in some obscure but heavily depended on package could actually be relatively easy.
> 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/
https://reproducible-builds.org/reports/2019-07/
All the npm cases I can think of have been in javascript code, not 'binaries'. So that wouldn't have prevented any of them.
Fair point. For Javascript there is no binary step so it has to be in the source code. In compiled languages, this is different: you can hide it in the binary, and finding it there is much harder than checking the source code VCS history. So without reproducible builds, compiled package managers would be in an even worse situation than Javascript, at least what ability to review the uploaded packages is concerned.
Ultimately the problem doesn't have a good solution right now. Reproducible builds are a part of the solution, as is making it harder for malicious debian packagers to upload infected binaries. You need to protect the entire supply chain.
Ultimately the problem doesn't have a good solution right now. Reproducible builds are a part of the solution, as is making it harder for malicious debian packagers to upload infected binaries. You need to protect the entire supply chain.
It makes absolutely no difference when binary packages are compiled on a trusted build farm, i.e. like everyone does already.
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.
> all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted
None of those package repositories are maintained by a limited set of curators.
Debian's repositories and other linux distributions repositories are curated.
Uploading a malicious package to npm is as easy as typing 'npm publish'.
> "reflections on trusting trust"
It's a very useful piece of art and a thought experiment.
In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery.
A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).
None of those package repositories are maintained by a limited set of curators.
Debian's repositories and other linux distributions repositories are curated.
Uploading a malicious package to npm is as easy as typing 'npm publish'.
> "reflections on trusting trust"
It's a very useful piece of art and a thought experiment.
In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery.
A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).
The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. Built artifacts as exist on disk in the repo are a relatively small piece of that.
> None of those package repositories are maintained by a limited set of curators.
It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone".
Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html
Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in...
Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux...
Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found...
Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repos...
Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...
> None of those package repositories are maintained by a limited set of curators.
It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone".
Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html
Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in...
Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux...
Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found...
Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repos...
Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...
I don't like when "Reflections on trusting trust" is used as an excuse to throw the hands in the air and not doing anything. Sure, it's not perfect, but the reproducible-builds people are doing important work that makes it considerably harder to inject malware into distribution repos.
The hard part about the security of built artifacts is not building them, it's auditing the source looking for bugs. Reproducible-builds doesn't audit the source, but many act like they think it does. Added to this is the host of other security issues with the chain between the developers keyboard and your system. This solves none of them, but many act like they think it does.
Therefore, in my view it provides a smallish real benefit and a large moral hazard.
Therefore, in my view it provides a smallish real benefit and a large moral hazard.
I'm sorry, but the logical fallacy of "We must do something; This is something; Therefore, we must do this." is the worst attitude to have for security. Not only you will never end with anything actually important done, it will also justify all the evil that will be done in the name of security.
And nobody says that not doing anything is ok, but please do it properly, do some basic threat modeling first.
P.S. I'm not against reproducible builds, I think they are useful for many things, just not for security. They may even let us do decentralized trustless peer-to-peer build system someday.
And nobody says that not doing anything is ok, but please do it properly, do some basic threat modeling first.
P.S. I'm not against reproducible builds, I think they are useful for many things, just not for security. They may even let us do decentralized trustless peer-to-peer build system someday.
> The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters.
There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem.
[1] https://in-toto.github.io/
There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem.
[1] https://in-toto.github.io/
Science is hard. Superstition is fast and might save your job, at least for awhile.
I want this on a shirt.
>A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood
Except for that time that Debian developers "knowing better" completely neutered most cryptography on all updated Debian systems[1]:
>Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.
Massive, rapid key rotation schemes had do be implemented to cover their screwup because all keys were trivially enumerable, to the point where all affected keys were blacklisted[2].
[1] https://www.debian.org/security/2008/dsa-1571
[2] https://security.stackexchange.com/questions/3422/what-is-th...
Except for that time that Debian developers "knowing better" completely neutered most cryptography on all updated Debian systems[1]:
>Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.
Massive, rapid key rotation schemes had do be implemented to cover their screwup because all keys were trivially enumerable, to the point where all affected keys were blacklisted[2].
[1] https://www.debian.org/security/2008/dsa-1571
[2] https://security.stackexchange.com/questions/3422/what-is-th...
Reproducible builds can't prevent hidden malware. They don't do much at all for security.
They can't prevent it but they can help it become visible. Without reproducible builds, nobody has an easy way to verify that a specific binary corresponds to a specific deemed safe bit of source code. There can still be source code based attacks by upstream maintainers of course. In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse.
> In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse.
This is incorrect. It wouldn't make a single difference.
This is incorrect. It wouldn't make a single difference.
It forces logging of the malware, globally. That's worse than maybe getting caught.
If you assume that the build systems and the distribution are secure.
If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.
If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.
Bugs in the build system are just bugs, quite possibly security bugs but still set in stone. Reproducible builds have no point if you distribution is broken and cant actually cant verify they are reproduced. You could have just asked "What if the reproduced build isn't?". It's not a reason to not be able to reproduce the image.
We know how to publish the input and output hashes. It's one of the use cases for a global ledger. Using CF's trust root would be pointless.
We know how to publish the input and output hashes. It's one of the use cases for a global ledger. Using CF's trust root would be pointless.
Nix/Guix are quite cool to tackle this.
They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries.
Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there.
There's e.g. Vulnix that scans for CVEs [1].
[1] https://github.com/flyingcircusio/vulnix
They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries.
Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there.
There's e.g. Vulnix that scans for CVEs [1].
[1] https://github.com/flyingcircusio/vulnix
I believe they aren’t just progressing towards reproducible builds, but that the whole system is already predicated on them. In Nix, you have to make special exceptions for packages that aren’t rebuildable from source.
Rebuildable is different than reproducible. The Nix system is predicated on rebuilding. Ideally the binaries would be all also reproducible however it turns out making compilation completely deterministic is actually pretty hard. When we reach that point and me and you can both independently produce identical binaries and hash them from exactly the same source code that is beyond fantastic for security and auditing.
r13y.com tracks the progress for NixOS reproducibility (well, for the tiny subset of nixpkgs that forms the minimal ISO image at least).
[deleted]
NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them.
(edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
(edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
You can also build regular packages, no matter how complicated they are, by spanning an FHS environment. That's sort of a sandbox that simulates a regular Unix environment with whatever dependencies you need in the usual places (/bin, /usr, ...).
Of course, you loose some Nix advantages. But it's a great way to get a regular Unix environment for one-off things or desperate cases.
Of course, you loose some Nix advantages. But it's a great way to get a regular Unix environment for one-off things or desperate cases.
Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
Hasn't this happened a few times? IIRC the AUR had some malware last year, but it was caught pretty quickly. I think why it doesn't happen often is more visibility thing. If it's a useful virus then it's going to be in a popular package, for maximum contamination (or at least some threshold). But people using things like the AUR are generally much more tech savvy then you're average computer user and will correctly flag a package as malicious much faster. Plus there is a higher percentage of users looking at commits. So if they get caught fast then there's more protection for the less savvy (or "lazy"). This is just a guess though.
I think people inspect AUR packages before compiling, at least I do, so something obvious will be caught. But something like backdoor hiding in plain sight as an RCE vulnerability or even just more obvious code sneakely integrated into the source and waiting for a specific time far into the future to activate is very unlikely to be caught.
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.
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.
FWIW, as far as "scrutiny" goes, I think the track record of Red Hat and Debian/Ubuntu on this stuff is about as good as... well, basically any other distribution system I'm aware of. The Android and iOS stores have hosted malware, as has Microsoft's. Steam has pushed bad stuff. NPM is a straight up train wreck...
I mean, I agree in principle that it's a hard problem. But the actual solution we've landed on in the Linux world seems like... well, just not really the first thing we should be worried about.
I mean, I agree in principle that it's a hard problem. But the actual solution we've landed on in the Linux world seems like... well, just not really the first thing we should be worried about.
That's definitely the feeling I've gotten from the Debian repositories, which are very cautious about what to distribute. I was thinking about it in the abstract.
What's the solution? I would argue that the Linux model is way more secure than the windows model of "Google your software and download it from whatever website pops up". It also allows for much more freedom and availability than the locked down macos app store.
It's a tough balancing act.
It's a tough balancing act.
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!
Haven't used Putty (or Windows, for that matter) for a while, but the site does not look sketchy at all. It looks like either a two decades old site, or a site of someone who purposely objects the modern web design tendencies (and believes some of the earlier mantras of web design, like user should have control of line lenghts by resizing their window).
A "sketchy" web site is the one festered with ads, pop-ups, seemingly modern-looking but with no actual content or with dead links...
A "sketchy" web site is the one festered with ads, pop-ups, seemingly modern-looking but with no actual content or with dead links...
Depends on the attack vector. If the concern is inadvertent malware (i.e. an unaware developer incorporating a malicious library etc.) then I'd suspect the package repos would be a bit safer because they tend to act as a low pass filter (active source repos can change very frequently, downstream package repos much less so) and also act as one or more additional sets of eyes on the source code. Some developers can get so focused on getting things done that they can lose sight other aspects of their application.
I've heard far more stories about malware making it into developer repos (usually inadvertently) than making it to package repos. I suspect it's partially the relative areas of focus of developers vs package maintainers and partially just having another set of eyes at least glancing at what's going on.
I've heard far more stories about malware making it into developer repos (usually inadvertently) than making it to package repos. I suspect it's partially the relative areas of focus of developers vs package maintainers and partially just having another set of eyes at least glancing at what's going on.
Ahh the attack vector. Here’s a free one: KDE addons for things like themes and wallpapers. The package format allows running of arbitrary code. Well obfuscated stuff gets through (to the tune of 10k+) all the time. Pretty sure I inherited a malware or two from there in the past
I'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.
Some skiddies use Kali Linux but only because they managed to follow step-by-step instructions on YouTube without which they're lost.
> Most malware code I've seen is terribly written and barely works.
Yeaah cause someone is just going to be so kind enough to share their perfect example of what malware code should look like to the rest of the world.. (actually there's an F ton available on Github, quasar, pupyrat, etc) Don't be so naive man. As a hobbyist malware programmer myself, I know that you don't know what you're really talking about other than pointing out skids targeting Windows (cause most available malware/RATs are targeted for windows) and use Kali cause-so-many-yt-tutorials.
edit: fwiw, I find it much easier writing malware under *nix cause they come with python and a bunch of dev libs, where as windows I have to dynamically load libraries in sneaky ways. Also implementing rootkits & RunPEs can be pretty damn puzzling -- definitely not that easy as you say
Yeaah cause someone is just going to be so kind enough to share their perfect example of what malware code should look like to the rest of the world.. (actually there's an F ton available on Github, quasar, pupyrat, etc) Don't be so naive man. As a hobbyist malware programmer myself, I know that you don't know what you're really talking about other than pointing out skids targeting Windows (cause most available malware/RATs are targeted for windows) and use Kali cause-so-many-yt-tutorials.
edit: fwiw, I find it much easier writing malware under *nix cause they come with python and a bunch of dev libs, where as windows I have to dynamically load libraries in sneaky ways. Also implementing rootkits & RunPEs can be pretty damn puzzling -- definitely not that easy as you say
> As a hobbyist malware programmer myself, I know that you don't know what you're really talking about
Let's see some of your code.
Let's see some of your code.
Maybe if it's 'good' you don't see it? Like we only hear about the criminals that get caught...
The funny thing is the most advanced malware out there today (that we know of) was created by the US and Israeli governments.
[1] https://www.symantec.com/security-center/writeup/2010-071400...
[2] https://www.computerworld.com/article/2934593/duqu-2-0-kaspe...
[1] https://www.symantec.com/security-center/writeup/2010-071400...
[2] https://www.computerworld.com/article/2934593/duqu-2-0-kaspe...
[deleted]
Its 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 malware vectors - both exploited software and injected binaries. GUI desktops could have provided UI to prompt users for unknown programs trying to access specific things and then send reports upstream of programs allowed for review. It would practically be a self-building database of program file access if done right.
But that isn't the only avenue to it. You could pressure upstream to include discriptor files in git repos of a standardized format of file access for each binary that can be used to generate selinux / apparmor / tomoyo rules. You could do it the really hard way and just have a sprint to surface test every program in official repos and generate such files yourself. Programs should almost never be accessing anything outside their XDG conf file and data dir - they should be linking libraries to provide access to other stuff (input, gui, etc) and file access should go through the system wide file picker.
As it is right now though pretty much every executed binary on most Linux systems is allowed to do whatever it wants that it has user access privilege to. Especially because most maintainers don't want to have to bother with the complaints of malcontent software breaking constantly trying to read arbitrary files. The Apparmor profiles of SUSE / Ubuntu or SELinux of Fedora are largely written for a few specific programs, usually web browsers and file sharing daemons, rather than be comprehensive. Its such a shame that all the technologies exist and are in place to make this work (even Arch has Apparmor support in its official repos now!) but there is no willpower / capital / interest in going the last step and trying to be all encompassing in your MAC profile and then lock down unknown programs appropriately. Android pretty much does this already, its a shame desktop Linux totally skipped over this avenue towards secure desktops.
There is of course an argument that if you lock down programs with network access then thats all you need to secure your desktop but that position falters in the face of arbitrary programs being run at random that can include network access. The goal should be a default restricted profile - one where arbitrary binaries cannot do whatever they want to your system, in the context of having a comprehensive profile database of software being used that covers 99% of real world program usage and thus doesn't impose a sizable UX burden of constant usage prompts for common applications.
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 malware vectors - both exploited software and injected binaries. GUI desktops could have provided UI to prompt users for unknown programs trying to access specific things and then send reports upstream of programs allowed for review. It would practically be a self-building database of program file access if done right.
But that isn't the only avenue to it. You could pressure upstream to include discriptor files in git repos of a standardized format of file access for each binary that can be used to generate selinux / apparmor / tomoyo rules. You could do it the really hard way and just have a sprint to surface test every program in official repos and generate such files yourself. Programs should almost never be accessing anything outside their XDG conf file and data dir - they should be linking libraries to provide access to other stuff (input, gui, etc) and file access should go through the system wide file picker.
As it is right now though pretty much every executed binary on most Linux systems is allowed to do whatever it wants that it has user access privilege to. Especially because most maintainers don't want to have to bother with the complaints of malcontent software breaking constantly trying to read arbitrary files. The Apparmor profiles of SUSE / Ubuntu or SELinux of Fedora are largely written for a few specific programs, usually web browsers and file sharing daemons, rather than be comprehensive. Its such a shame that all the technologies exist and are in place to make this work (even Arch has Apparmor support in its official repos now!) but there is no willpower / capital / interest in going the last step and trying to be all encompassing in your MAC profile and then lock down unknown programs appropriately. Android pretty much does this already, its a shame desktop Linux totally skipped over this avenue towards secure desktops.
There is of course an argument that if you lock down programs with network access then thats all you need to secure your desktop but that position falters in the face of arbitrary programs being run at random that can include network access. The goal should be a default restricted profile - one where arbitrary binaries cannot do whatever they want to your system, in the context of having a comprehensive profile database of software being used that covers 99% of real world program usage and thus doesn't impose a sizable UX burden of constant usage prompts for common applications.
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. These people are the worst positioned to understand which privileges are needed, when they're needed, and how to constrain them. They're certainly not well acquainted with the software and how it operates. The only tools at their disposal are external policy mechanisms which are often extremely difficult and complex to use to achieve the desired level of access with the external environment. And they're incapable of refactoring the target software to improve the situation. It shouldn't be any surprise, then, why these resources are underutilized.
seccomp is an improvement but it's much too low-level. Other than the obvious issues that a simplistic syscall filtering mechanisms is too brittle, seccomp 1) doesn't support file paths, and 2) the inheritance semantics makes it nigh impossible to refactor existing code which invokes other programs while 3) also setting a high bar of minimal complexity for new code. Again, no surprise why this resource is underutilized.
This is why OpenBSD's pledge and unveil are infinitely easier tools for securing programs. They were conceived and refined with the goal of making it easy to lock down programs, not to maximize purely abstract requirements like fine-grained control or administrator flexibility. And in any event tools like file permissions and other access controls remain readily available to augment the built-in privilege restraints.
Android is a poor example, especially for server systems, because Android programs don't need to interoperate directly with each other. Whereas on server systems the degrees of interoperability and dependence of various pieces of software are extremely complex and varying. One alternative, forcing everyone to write microservices, at best simply shifts the burden around; it doesn't help to minimize that burden, nor does it permit us to incrementally and organically improve the situation.
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. These people are the worst positioned to understand which privileges are needed, when they're needed, and how to constrain them. They're certainly not well acquainted with the software and how it operates. The only tools at their disposal are external policy mechanisms which are often extremely difficult and complex to use to achieve the desired level of access with the external environment. And they're incapable of refactoring the target software to improve the situation. It shouldn't be any surprise, then, why these resources are underutilized.
seccomp is an improvement but it's much too low-level. Other than the obvious issues that a simplistic syscall filtering mechanisms is too brittle, seccomp 1) doesn't support file paths, and 2) the inheritance semantics makes it nigh impossible to refactor existing code which invokes other programs while 3) also setting a high bar of minimal complexity for new code. Again, no surprise why this resource is underutilized.
This is why OpenBSD's pledge and unveil are infinitely easier tools for securing programs. They were conceived and refined with the goal of making it easy to lock down programs, not to maximize purely abstract requirements like fine-grained control or administrator flexibility. And in any event tools like file permissions and other access controls remain readily available to augment the built-in privilege restraints.
Android is a poor example, especially for server systems, because Android programs don't need to interoperate directly with each other. Whereas on server systems the degrees of interoperability and dependence of various pieces of software are extremely complex and varying. One alternative, forcing everyone to write microservices, at best simply shifts the burden around; it doesn't help to minimize that burden, nor does it permit us to incrementally and organically improve the situation.
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.
> 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.
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.
> The person best positioned to lock down a program is the developer.
The person best positioned to lock down a program is the maintainer of the platform on which all the other programs run.
In fact the individual program developers should strive not only to ignore security altogether, but to develop a common set of tools that delivers arbitrary third-party code to the user's machine. This makes security theater unlikely as any given developer will only have expertise in their program proper and not in the security of their program plus the arbitrary third-party code. This also ensures maximum velocity of domain-appropriate development and focuses on ease of program installation-- the exact opposite of the problem being parodied in the article.
That velocity will rapidly grow the platform. This neutralizes any efforts to thwart progress through ad hoc program lockdown as futile. At the same time it puts massive pressure on the platform itself to gracefully handle misbehaving programs lest systemic insecurity decrease installation velocity.
Thus you get a system where arbitrary programs may be installed as quickly as possible with a security model that works even if 100% of the programs installed are malicious.
The cost is that arbitrary user data is exfiltrated during most program installations and runtimes (but that is a minor implementation detail).
The person best positioned to lock down a program is the maintainer of the platform on which all the other programs run.
In fact the individual program developers should strive not only to ignore security altogether, but to develop a common set of tools that delivers arbitrary third-party code to the user's machine. This makes security theater unlikely as any given developer will only have expertise in their program proper and not in the security of their program plus the arbitrary third-party code. This also ensures maximum velocity of domain-appropriate development and focuses on ease of program installation-- the exact opposite of the problem being parodied in the article.
That velocity will rapidly grow the platform. This neutralizes any efforts to thwart progress through ad hoc program lockdown as futile. At the same time it puts massive pressure on the platform itself to gracefully handle misbehaving programs lest systemic insecurity decrease installation velocity.
Thus you get a system where arbitrary programs may be installed as quickly as possible with a security model that works even if 100% of the programs installed are malicious.
The cost is that arbitrary user data is exfiltrated during most program installations and runtimes (but that is a minor implementation detail).
The distributions don’t have unlimited resources and the community can be a real deterrent: look at how much crap the systemd developers get every time they fixed a decades-old problem and then the angry mob shows up to complain about having to learn something new.
I’ve been hoping that we’ll get there for a couple decades but SELinux was quite the reminder that when faced with work a lot of people will just turn off a security measure and rant about it rather than contributing.
I’ve been hoping that we’ll get there for a couple decades but SELinux was quite the reminder that when faced with work a lot of people will just turn off a security measure and rant about it rather than contributing.
Oh, try calling in for support on that $1+M CommercialDatabase(tm) installation and tell them SELinux is turned on, or any other similar super expensive software. The 1st line will happily tell you that the most prized data you were willing to pay huge amounts for can't be protected by something so .. easy as SELinux.
They will not take your ticket until you turn it off and try again, and to your great surprise they will not be sharing their favourite selinux tagging configs with you.
So in the end, what can be protected with a decent SElinux config will be that statically generated catblogs-r-us.io site you run, but not the company financial database. "Priority inversion", or something to that effect.
They will not take your ticket until you turn it off and try again, and to your great surprise they will not be sharing their favourite selinux tagging configs with you.
So in the end, what can be protected with a decent SElinux config will be that statically generated catblogs-r-us.io site you run, but not the company financial database. "Priority inversion", or something to that effect.
Yes - things like that are a huge problem. For a field which often calls itself engineering I’m frequently disappointed by how many significant calls are based on superstition rather than analysis.
I like the pledge model. If one's assumptions are wrong, the program fails.
https://man.openbsd.org/pledge.2
https://man.openbsd.org/pledge.2
It's conceivable that this is the real reason. Maybe Windows is a "dragon king" statistical outlier in terms of malware. As an example, every once in a while a file "type" that previously nobody knew could be executed causes problems because someone finally figures out that it could be executed. MacOS certainly has problems with malware, but not even to the same order of magnitude as Windows.
The security of GNU/Linux is based mostly on people not being particularly interested in exploiting Linux users ... because they are more sophisticated and because there are less of them.
If Linux ever becomes useable for the average consumer and its adopted widely, we will see plenty of viruses for it.
I'm more optimistic about systems like Fuschia which are capability-based from the kernel up.
If Linux ever becomes useable for the average consumer and its adopted widely, we will see plenty of viruses for it.
I'm more optimistic about systems like Fuschia which are capability-based from the kernel up.