Re: Software
Actually, sandboxing is the answer and signed code is not.
It is often quite hard to differentiate between code and data. That vb code is just data to the vb interpreter.
The problem is that the os doesn't sandbox apps and there is no rights hierarchy. Why would you allow excel to access system settings? Why would you allow excel to execute binaries outside of /office/excel/bin? Why wouldn't the os by default restrict executable's ability to run further executables to the subtree of the initial executable? Why can't I tell the os not to allow excel access to anything but "My Documents"? Does it want to load and run vbscript? Sure, but that vbscript inherits excel's rights and can only access files in My Documents too.
Why not have a read-only $binpath and $docpath inherited and set automatically on execution? Then that browser flaw allows ransomware to encrypt your browser app and your Downloads directory. Meh.
How about a flag to allow network access or it gets none? How about a flag which allows raw sockets or uri's which are logged/submitted to os security for approval? A built in local proxy service. Admin-installed packaged apps get to declare resource requests, but everything else is sandboxed by the os.
These may not be appropriate for high throughput servers, but for desktops and exposed systems? I thInk so!
Biting the hand that feeds IT
