> What would you think about sandboxing all media related components?
You have to be very _specific_ when you say _sandboxing_.
Since, the attack surface is mostly at the decoding layer - there are at least few dozen ways to sandbox the processing logic on modern UNIX-like OS based on the requirements:
1. Farm out, give it its own namespace and filtered list of seccomp2 calls to do the decoding.
2. Farm out, compartmentalize the decoding layer to BSD jails
3. Same as 2) but using chroot - give the necessary libs/bins/mount
4. Farm out, run the decoding components on a separate VM - somewhat akin to QubeOS.
5. Farm out, run ephemeral spark jobs to process the decoding on a compartmentalized VMs/Containers....
These days the word _sandbox_ is overloaded.
It used to be that you put things that are in userland under selinux and go to bed at night.....
lsofzz|5 years ago
You have to be very _specific_ when you say _sandboxing_. Since, the attack surface is mostly at the decoding layer - there are at least few dozen ways to sandbox the processing logic on modern UNIX-like OS based on the requirements:
1. Farm out, give it its own namespace and filtered list of seccomp2 calls to do the decoding.
2. Farm out, compartmentalize the decoding layer to BSD jails
3. Same as 2) but using chroot - give the necessary libs/bins/mount
4. Farm out, run the decoding components on a separate VM - somewhat akin to QubeOS.
5. Farm out, run ephemeral spark jobs to process the decoding on a compartmentalized VMs/Containers....
These days the word _sandbox_ is overloaded.
It used to be that you put things that are in userland under selinux and go to bed at night.....