No, it is unfit for this purpose. The reason is:
- you need to specify the rules before starting an application. How one is supposed to guess what application will do? Figuring out the correct rules may take lot of time and is impossible for non-programmers. Imagine I want to install 10 apps per day and they should work perfectly, how much time will I be spending writing rules?
- the rules cannot be changed in runtime, for example, giving access to a camera for 1 minute
- the rules are too limited. You can restrict access to a file, but can you restrict access to a DBUS bus? Can you restrict access to audio, video, GPU etc? To /proc filesystem? To a DNS domain? The rules feel like they were written for computers with teletypes from 70s and not for modern machines.
- they do not allow providing fake data, for example, a fake list of WiFi points so that the app thinks it has the access to your geolocation while in reality is doesn't.
So it is some outdated technology unfit for modern day.
What does a user want? The user wants to be able to run anything without any risk and without writing any config files. Obviously it takes a skill to write such OS, and there is definitely a lack of people with this skill among Linux distribution creators.
A system where installation is done using "curl + sudo bash" is the opposite of a safe OS.
> A system where installation is done using "curl + sudo bash" is the opposite of a safe OS.
not clear at all. E.g. on QubesOS this could be fine
>Imagine I want to install 10 apps per day
Either you're engaged in some large-scale testing operation and your automation already handles it, or something has gone terribly wrong and the inconvenience of the sandboxing UI is the least of your concerns.