4 ms·

Try to not think in terms of whole applications. Chrome already has threads/processes dedicated to executing untrusted JavaScript code. What seems to be lacking

by zbuf 6y ago

Try to not think in terms of whole applications. Chrome already has threads/processes dedicated to executing untrusted JavaScript code. What seems to be lacking is providing developers with an easy and non-root mechanism to run these as a different UID. To isolate the whole app should be possible, yes -- but it's also a sledgehammer. Yes, for the reason you describe, inter-operability with your own UID is actually good. My previous job taught me just how much this can be a feature not a bug; we made extensive use of applications, plugins and various forms of IPC to allow desktop applications to inter-operate in powerful ways. There are other mechanism already exist. When a process (or thread) is forked, various resources can be passed over the boundary; file descriptors, shared memory etc.. For example, where un-trusted code needs access to a file, the mechanism to do that is already there in a nice "opt-in" manner.

touisteur 6y ago
You keep pushing away namespaces but (as I'm sure you know) you can make a thread join a namespace. I do this with network, mount and user namespaces, to get some separation and be able to put strict firewall, mount rules in place. Since you can put uid and gid in firewall rules it makes for interesting belts and suspenders component separation. Combined with ZeroMQ, and SPARK and lots of generated code for the inter-thread comm and you can build modular designs. Just don't look at you ip link / ifconfig :-)