3 ms·

Imagin an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. OS X does this for sandboxed apps: ht

Imagin an OS where applications/serices each get their own mini-filesystem, without ability to access each other's data. OS X does this for sandboxed apps: https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html#//apple_ref/doc/uid/TP40011183-CH1-SW1 https://developer.apple.com/library/mac/documentation/Securi... All apps from the App Store are sandboxed.

java-man 12y ago
What I meant is the app/service isolation on the OS level. It should not apply just to a subset of apps, but to each and every process that runs on a device.
- danieldk 12y ago
  Because then every application would be an island and useless. Red Hat Linux tried a variation of this with the SELinux policy that preceded the 'targeted' policy (I forgot its name). Processes that did not have a policy adding permissions would be allowed to virtually read/write nothing. The net result was that nearly everyone switched off SELinux. Afterwards, Red Hat worked in the opposite direction. In the so-called 'targeted' policy processes are allowed to do what a normal UNIX process is allowed to do, unless there is a policy defined for them. Since they provide policies for commonly used daemons it adds security, while not making life too hard for sysadmins. Net result: most people keep SELinux enabled and have safer systems.