On Mon, Mar 13, 2017 at 12:11:51PM -0300, [email protected] wrote: > Hey Valoq, > > thank you for working on this. Actually I was waiting on the sandboxing > project > from flatpak to be more complete before trying to do a sandbox for evince. As > far s I know, flatpak is using bubblewrap among its technologies for > sandboxing. Also, there are Gtk portals that let you do very fine grained > restricted access to the filesystem inside a flatpak environment. It would be > great if we could have only one interface for sandboxing... Like you want > evince to be sandboxed even if it's installed in a normal way, not the flatpak > way. Anyway, these are just some thoughts > > Cheers > > José >
Yes that is correct, bubblewrap is used by flatpak so that is actually covered. There is however another big difference between using flatpak/portals and integrated sandbox support. By integrating sandboxing into the application itself, the resulting protection can be significantly greater. Chromium demonstrates how to do this right actually. Their rendering processes are completely isolated and exploiting chromium is quite a challenge. The same can be archived for evince but this is only possible by working on the evince code itself instead of just wrapping a container sandbox around it like flatpak does if I understand it correctly. I have covered the topic on this page: https://linuxsandboxingproject.github.io/ Also I would like to point out that using seccomp inside of evince should not affect flatpak at all. There should not be anything to keep one from using both, but by integrating seccomp in evince directly the feature can be used by everyone that does not use flatpak as well. When combined with flatpak/bubblewrap the protection is even greater of course. > > > On Thu, Mar 9, 2017 at 8:45 PM, valoq <[email protected]> wrote: > > Hello everyone, > > a short while ago I completed a project about sandbox technologies on > linux and evince was one of the target applications for which I > implemented a basic Sandbox. Now that I have finished my work I would > like to ask if you are interested in using the results and integrate > sandbox suppport for evince. > > There are still a few things that need work, like gui support as well > as some adjustments of the makefiles. > > The sandbox uses (lib)seccomp to restrict the application using two > different modes. A invisible sandbox mode that does not affect the > normal functionality at all and that will not be noticed by the user > (this can be used as the default), as well as a read only mode that > allows only the systemcalls used by evince to read local files (network > access disabled). There are still a few weakpoint that need to be > considered like access to dbus (and sockets in general), which can be > disabled by seccomp as well but needs some adjustments of the internal > workings of evince. Another issue is the x-server but this can simply > be resolved by using wayland (still works on X11 but does not isolate). > What still needs to be done is to prevent launching a browser to open > external links. At the moment this causes the application to crash > (since seccomp blocks this) but this can befixed easily, I just have > not found the correct line yet that handles this. > > The seccomp sandbox code can be found here: > https://github.com/LinuxSandboxingProject/evince > > I also build additional sandbox isolation by using linux namespaces but > there is actually already pretty nice (and better) code that does that > (bubblewrap) and while I am not sure you want to include that by > default, here is a helper script that further isolates evince using > namespaces (isolating the filesystem, process and user environment as > well as the network interfaces) > https://github.com/valoq/bwscripts/tree/master/profiles > > Seccomp alone already does some nice hardening and can be easily > integrated (some more tests are advised). Combined with namespaces the > resulting sandbox is even more solid. > > If you are interested in using this code in the official evince project > I would be happy to help with any resulting issues regarding the sandbox > support. > > _______________________________________________ > evince-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/evince-list > > >
signature.asc
Description: PGP signature
_______________________________________________ evince-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/evince-list
