3 ms·
Performance has absolutely nothing to do with sandboxing. Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty direct
by nolist_policy 3y ago
Performance has absolutely nothing to do with sandboxing.
Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user.
This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS.
The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).
- michaelt 3y ago> Performance has absolutely nothing to do with sandboxing. In theory, sure. In practice, when Ubuntu added a sandbox to the calculator it started taking longer to start than Eclipse. Took them about 4 years to fix it.
- pjmlp 3y agoMore a matter of execution than the technology. Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.
- josefx 3y ago> Performance has absolutely nothing to do with sand boxing. Even simple optimizations like shared caches fall afoul of proper isolation. In the past browser caches could be abused to find out if a user frequented specific sites just by checking how long it would take to request a site specific resource. Result: no more shared caching, all resources had to be loaded for each site separately.