an infected vm is no victim. Lets say you downloaded a pirated game which also has malware in it. You play said game in a vm specifically made _for_ that game. So the malware only runs when you are actually using the vm.
You'd have a vm for each specific piece of software that is untrustworthy, and sharing of files can occur thru sanctioned channels (such as a local, safe temp directory shared by each vm, or read only mounts).
Well, you could include the standard file operations (launch program by doubleclicking that file, save that particular file; secure "save-as" selection provided by OS) as managed parts of the sandbox; and have a functional app that is unable to open&change any files that the user doesn't intentionally choose.
Comments
an infected vm is no victim. Lets say you downloaded a pirated game which also has malware in it. You play said game in a vm specifically made _for_ that game. So the malware only runs when you are actually using the vm.
You'd have a vm for each specific piece of software that is untrustworthy, and sharing of files can occur thru sanctioned channels (such as a local, safe temp directory shared by each vm, or read only mounts).
Aren't you reinventing app sandboxes here?
That's a good question - why don't modern consumer OSes offer simple, convenient one-click app sandboxing?
Because programs operate on files which need to be accessible by other programs. This is the whole point of files with interoperable file formats.
The applications that does not do this, i.e. games, are good candidates for sandboxing, but normal applications? Not so much.
Well, you could include the standard file operations (launch program by doubleclicking that file, save that particular file; secure "save-as" selection provided by OS) as managed parts of the sandbox; and have a functional app that is unable to open&change any files that the user doesn't intentionally choose.