Originally posted by Danny3
View Post
It's a successor to distro-specific package managers for applications which run in a desktop session and it implements Android/iOS-like application sandboxing, relying on Wayland to eliminate X11 APIs as a way to escape the sandbox.
It can sandbox any application, since it relies on a mixture of technologies like cgroups and seccomp, and some applications require no modification at all, since integrations are done within GTK+ or Qt when possible. (Here are blog posts announcing support progress by KDE [2] and GTK+ devs.)
...and, even if an application wants/needs "allow everything", it's still in its best interest to use Flatpak because the GTK+ and Qt integrations finally allow Qt applcations and GTK+ applications to share the same desktop-defined Open/Save/Print dialogs.
Originally posted by elvenbone
View Post
First, you use the IOMMU to ensure that DMA-capable devices can't be used to escape the sandbox by tampering with memory not granted to them.
For PCI-E devices, you've generally got a more specific driver handling that, such as the GPU driver (search for "GPU virtualization"), network driver (search netfilter, seccomp, cgroups, etc.), etc.
For USB devices, you don't even get DMA unless you're on USB 3.1. Beyond that, they're like network sockets in that the kernel handles the transport protocol and another kernel module or userspace driver requests to bind to a specific USB endpoint in the same way you'd ask to connect to an IP+Port combo.
Flatpak already has the Device portal for requesting access to the speakers/camera/microphone. All it would take is either extending the Device portal or adding another portal to allow a Flatpak'd application to specify that it wants to be the exclusive owner of a USB device with a specific VID+PID combination without having to relax the sandbox rules enough to over-grant permissions within /dev.
Comment