[marcodiego]

Most software used comes from repositories. Most of the time the user is not logged in as root. Any virus would have to exploit a system vulnerability, if that is common and serious enough to cause harm then anti-virus software will take longer to catch than it will take to be automatically fixed by updates.

[paranoidrobot]

> Any virus would have to exploit a system vulnerability,

I'm not sure if by virus you mean some specific definition, but malware can still result in a very long and painful day/week/whatever with just access to your home directory and nothing else.

What would happen if your ~/.aws folder was piped to pastebin? Even if you're using short-lived STS sessions with ephemeral keys, I imagine most people would still find themselves in a world of hurt.

How about sending interesting files from your browser's userdata directory? All your cookies, your browser's password manager, possibly copies of your third-party password manager's cache (even if it's all encrypted), copies of cached files, your Downloads directory.

[markhahn]

calling home or exfiltration is indeed a serious threat. otoh, it's fairly straightforward to partition / reduce / sandbox environments in Linux. do you need to touch AWS infrastructure from the same account, host, vm as you read email or surf the web? do these environments need full, direct internet access?

[paranoidrobot]

> it's fairly straightforward to partition / reduce / sandbox environments in Linux.

Perhaps in some distros, but not so much elsewhere.

> Do you need to touch AWS infrastructure from the same account, host, vm as you read email or surf the web?

In short: Yes.

> do these environments need full, direct internet access?

Not sure what you mean by the environment, but in general, yeah - a whole bunch of tooling these days is basically unusable without internet access.

[charcircuit]

What percentage of desktop Linux users do that? Most distros don't do any sandboxing and those that do typically have easy ways to run binaries outside of a sandbox.

[charcircuit]

>Most of the time the user is not logged in as root

Why does this matter? Most malicious things someone would want to do don't require root. eg. VNC, DDoS, mic / webcam capture, token stealing, keylogging, ransomeware, stealing ssh / pgp keys, adware, backdoored web browsers. And for the small percentage that do you can just backdoor sudo or make a fake system update dialog that captures the user's password to let you have root whenever you want.

[markhahn]

it's fairly easy to resist lateral movement in Linux...

[jcrawfordor]

Two of the most ubiquitous categories of malware today are ransomware and agents used to steal secrets such as web browser sessions. Because both of these categories interact with files the user has access to anyway, privilege separation (especially only the basic form of privilege separation traditional on Linux) is of little help. The attack surface is all owned by the user anyway. Both sandboxing (such as kernel capabilities) and mandatory access control (SELinux) are helpful in reducing this possibility, but both of these are relatively difficult to use and so not common on workstations.

It's also reasonably common for an exploit to become known by AV vendors and have signatures released before it's been widely patched. Turnaround time from a major exploit becoming known to the industry to a signature release by AV vendors can be as short as a day, especially with the significant intelligence sharing that now happens in the AV industry. AV vendors sometimes release signatures before the exploit is publicly known as a result of information-sharing agreements, although this is a touchy issue because the signatures themselves become a form of public release. While keeping software up to date tremendously reduces risk, there is still a window of opportunity.

[captn3m0]

> Any virus would have to exploit a system vulnerability

XKCD 1200[0] disagrees:

> If someone steals my laptop while I'm logged in, they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission.

[0]: https://xkcd.com/1200/

[kaba0]

That’s one of my favorite xkcd comics because it describes the (very dire) situation so well. Unfortunately the linux userspace really doesn’t seem to care about security even a tiny bit, as if they were still living in the early days of computing where you could be naively trusting everything. And fortunately open-source software is indeed well-mannered for the most time, but that is no reason to be delusional.

Mobile OSs are way ahead in terms of security and the other two major desktop Os also does at least some mitigation against potential attacks. Yet our .ssh folder, web cache, backups everything can be read/written from the same user account one uses for npm installing any random package which has the potential to just encrypt your whole home directory..

[captn3m0]

I'm hopeful about efforts like bubblewrap, but widespread adoption is very tough. As long as policies are delegated (like AppArmor), I don't see that improving.

TPMs and Passkeys are also a good refuge - Just keep private material off the device.

What I'd like to see is a boundary between system installed packages (which I implicitly trust, but worried about malicious commits upstream, as others have noted) and other code, such as installed via pip, npm, cargo etc.

While it's feasible for me to audit a single shell script, or a PKGBUILD from AUR, it's pretty impossible for modern lanaguage package managers.