Re:The Windows installer of ImageMagick will no longer be si...
by michaelt on Sunday October 29, 2023 @10:34AM
(#38058983)
> 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.
Re:The Windows installer of ImageMagick will no longer be si...
by pjmlp on Monday October 30, 2023 @04:32AM
(#38066921)
More 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.
Re:The Windows installer of ImageMagick will no longer be si...
by josefx on Sunday October 29, 2023 @11:11AM
(#38059298)
> 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.
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, ...).