In the current LLM cybersecurity climate, I honestly can't say with 100% certainty anymore that something like a VM acts as a completely infallible sandbox environment for the next couple decades.
In the current LLM cybersecurity climate, I honestly can't say with 100% certainty anymore that something like a VM acts as a completely infallible sandbox environment for the next couple decades.
VMs are demonstrably not infallible, but that's not quite the issue here.
If you only ever run your banking app inside a VM with an encrypted disk volume, and don't browse sketchy sites or do anything else in there, then you're very well protected against even LLM-assisted attacks.
One caveat in that case is I wouldn't keep the password to the VM disk in a password manager, since that then becomes an attack vector.
A keylogger would still be a viable attack vector, though. The security of operating systems is going to need to be improved to guard against some of these things, e.g. a protected input mechanism for passwords that can't be intercepted.
Have you heard about "default allow" and "default deny" in the domain of cyber security? Traditionally PCs, especially for home use, were built around the former idea, where the user supposedly trusts most of the stuff installed.
The problem is that malware may sneak in, and then the user needs a horrible piece of software called anti-virus that needs to apply complicated heuristics to try and separate one from the other. It kind of worked ok for many years, but as the world evolved and the dangers kept increasing, little by little we have been going towards the other idea – default deny – where apps are considered harmful until proved otherwise, and the honest app developers have to jump through multiple hoops to get their apps available to users. That's the app store model, which kind of works, but is cumbersome and expensive for the app developer.
Anyway, going back to the VM discussion, I think we may end up applying the default deny idea further into the OS Kernel to reduce those risks further. After all, a small kernel has a much smaller risk surface and perhaps it can be formally verified to be secure under some reasonable assumptions.
That's definitely a big part of the issue - the idea that your local machine is a secure environment and that attacks from the inside are not as heavily defended against as attacks from outside via the network.
Agents turn that assumption on its head. It's not only default allow vs. deny, but also the design of many tools. E.g. the Linux utility `ls` has an `-exec` option which can execute a binary, which turns a tool that really should be a read-only directory inspection tool into something that can execute arbitrary code. That makes it unsafe to authorize agents to always be able to use `ls`, unless they're running in a tightly controlled sandbox.
All OSes are full of these kinds of traps, because it wasn't something people were paying much attention previously.
I think this is one of those situations where you don't need to outrun the tiger, you just need to be better at security than 99% of people, which is definitely the case if you're partitioning your life into VMs.
I wonder if/when mainstream OSes will start doing this.