4 ms·

No, you're missing reading the whole post, specifically the last sentence. That's the one to quote me on. Your browser has the role of bringing in untrusted co

by zbuf 6y ago

No, you're missing reading the whole post, specifically the last sentence. That's the one to quote me on. Your browser has the role of bringing in untrusted code, and running it. The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel.

DaiPlusPlus 6y ago
> The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel. What would be the privilege set of that new UID though? And it would be a poor UX if that separate UID had absolutely zero access to my (human) UID-secured files because then it wouldn't be able to access my browser cache and history - and I'd rather Chrome didn't decide to require each browser process to have its own non-shared cache. It's bad enough Chrome is now using 3.5GB for 4 windows (16 tabs total) on my desktop.
- 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 :-)

by zbuf 6y ago

DaiPlusPlus 6y ago

> The browser code would 'fork' a UID to run the untrusted code (and only that), and then we make good use of all the existing UID-based policy in the kernel. What would be the privilege set of that new UID though? And it would be a poor UX if that separate UID had absolutely zero access to my (human) UID-secured files because then it wouldn't be able to access my browser cache and history - and I'd rather Chrome didn't decide to require each browser process to have its own non-shared cache. It's bad enough Chrome is now using 3.5GB for 4 windows (16 tabs total) on my desktop.

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 :-)