Where I’d prefer to see time going is basically two areas: rather than trying to catch every possible bad thing, only allow know okay binaries to run (the hard part being supporting software developers), and extensive sandboxing to catch up with Apple. It’s hard to block every possible bit of bad code but we can minimize a lot of the damage if, say, a malicious PDF file didn’t mean the attacker could just read AWS credentials or SSH keys.
The other benefit is that AV software has a history of security problems. Most of that is that the vendors still use C like it’s the 90s and putting complex binary decoding logic into a privileged context is a recipe for bugs.
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.
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.
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.
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.
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.
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..
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.
[0] https://www.bleepingcomputer.com/news/security/antivirus-and...
[1] https://rack911labs.ca/research/exploiting-almost-every-anti...
Virus companies seem to focus much more on marketing then technical excellence. They typically run with full privs, regularly download code/rules from a central server, and are often written poorly. Seems like the industry is awash in security issues: buffer overflows, false positives, false negatives, not checking signatures on downloaded rules/code, and breaking various APIs, network protocols, etc by playing man in the middle. Even things like proxying SSL to scan traffic for SSL downloads ... but failing to check the cert.
So I see little value in running a closed source daemon from a anti-virus company to catch binaries that no serious attacker would use anyways. I trust the binaries from the OS's repos MUCH more than the antivirus programs. Similarly I don't trust IBM's BigFix that was malware Gateway used to help profit from tracking users and showing ads with their special "dock" that came installed on Windows systems. They of course made it very hard to uninstall, since that maximizes their profits.
Generally it seems like the wrong approach. If you want to do it right, have a whitelist for approved binaries. Ideally hooked up to your local mirror/repo so you can have approved signatures for all binaries BEFORE said binaries land on your Linux boxes. Spend whatever resources you would on anti-virus on patching, reporting, monitoring, firewalls, training, etc.
So in short, the questions we should be asking are:
1. How do viruses find their ways in?
2. And, what can be done (as a user or developer) to prevent that?
These are obvious, I know, and the software devs for Windows aren't deliberately writing insecure software, but these questions are ones better seen from a behavioural point of view.