5 ms·
If what you're trying to prevent is something in sandbox A messing with something in sandbox B, sure. If you want to prevent is malicious behavior generally, li
by thirsteh 14y ago
If what you're trying to prevent is something in sandbox A messing with something in sandbox B, sure. If you want to prevent is malicious behavior generally, like connecting to a botnet or exploiting a vulnerability in a system service, not so much. Then you need a mixture of sandboxing and whitelisting (rather than blacklisting), a combination that's unwelcome in most environments (a notable exception being app stores.)
- gizmo686 14y agoPart of the 'standard' model for security is to make every component as sandboxed as possible. The problem is, programs need to be able to access the system, and if the attack compromises the program it can do whatever the program can. For example, most web browsers have the ability to show html pages that are stored anywhere on your file-system. This means that if your web-browser gets infected, the attacker has full read access to you files. You can (and I do) sandbox your browser to only its files, however you then loose the features that depend on full read access. Of course, the instance of the javascript VM that is running the javascript from the website does not need filesystem access, so it can be, and normally is, sandboxed.
- ernesth 14y ago> The problem is, programs need to be able to access the system Not necessarily: to be on the Mac App Store, an application must access only files in its own resources (configuration and so on) or through user interaction (open file dialog). If your web browser gets infected, it gets full read access on every file you willfully want it to read. Problem, you cannot have a multimedia player that opens m3u playlist files in this model: see http://mplayerx.org/leave-mas.html http://mplayerx.org/leave-mas.html
- deleted 14y ago[deleted]