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.
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?
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.
> 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.
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.
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.?
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
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.
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".
>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.
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.
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.
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.
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.
> 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.
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.
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."
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...
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.
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.
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.
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.
That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.
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.
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.
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.
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.
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.
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...
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.
> 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.
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.
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.
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).
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".
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.
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.
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.
>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].
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.
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.
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.
> 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
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.
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.
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 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 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.
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.
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.
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.
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...
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).
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.
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:
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.
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.
116 comments
[ 3.7 ms ] story [ 187 ms ] threadFor 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.
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...
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.
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.
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
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.
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".
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.
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
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.
https://xkcd.com/1200/
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.
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.
So this is why the 'curl | bash' idiom feels like an anti-pattern to me...
Basically, the level of diversity in the ecosystem, while part of a reason for less widespread acceptance, also discourages any mainstream attacks.
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.
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
(edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
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.
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 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.
It's a tough balancing act.
A "sketchy" web site is the one festered with ads, pop-ups, seemingly modern-looking but with no actual content or with dead links...
https://reproducible-builds.org/reports/2019-07/
This is incorrect. It wouldn't make a single difference.
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.
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.
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.
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...
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/
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.
Therefore, in my view it provides a smallish real benefit and a large moral hazard.
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...
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.
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.
Some skiddies use Kali Linux but only because they managed to follow step-by-step instructions on YouTube without which they're lost.
[1] https://www.symantec.com/security-center/writeup/2010-071400...
[2] https://www.computerworld.com/article/2934593/duqu-2-0-kaspe...
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
Let's see some of your code.
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.
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.
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 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).
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.
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.
https://man.openbsd.org/pledge.2
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.
...although market share certainly also plays a part.
To say nothing of docker base images and popular docker containers...
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).
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.
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:
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"...
Oh, it's a joke. Got it.
Not sure what "uncommon" means but I think https://news.ycombinator.com/item?id=20682546 already documented that successful attacks are not rare.
"Unpatched KDE vulnerability disclosed on Twitter"
https://www.zdnet.com/article/unpatched-kde-vulnerability-di...