[tombert]

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.

[tptacek]

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".

[zaat]

>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.

[fao_]

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.

[raptorfactor]

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

[fao_]

Interesting! Looks like my memory failed me, the one time I don't double check...

[zaat]

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.

[Const-me]

> 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.

[jwkane]

lets not forget the "curl blahblah.com | sudo bash" bit-o-insanity.

[acdha]

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.?

[tombert]

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.

[saghm]

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?

[jwkane]

https://github.com/nodesource/distributions#installation-ins... I'm sure there are plenty of others.

[robrtsql]

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?

[waste_monk]

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...

[phaer]

> 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.

[saghm]

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)

[smnrchrds]

Relevant xkcd:

https://xkcd.com/1200/

[ChrisCinelli]

Without an effective application isolation a la iOS, itis exactly this.

[dinofacedude]

Ah, XKCD. Truly a blessing to the modern world!

[zuuow]

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

[pvorb]

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 ...`.

[wang_li]

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.

[Godel_unicode]

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.