On 17.07.2017 19:26, Richard W.M. Jones wrote: > On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote: >> On 16.07.2017 12:54, Richard W.M. Jones wrote: >>> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote: >>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote: >>>>> >>>>> If RPMs of the graphical application work fine now, what on earth is >>>>> the point of forcing packagers to make Flatpaks? Sandboxing isn't one >>>>> of them - as already explained, sandboxing is orthogonal to packaging. >>>> >>>> Huh? How would you get sandboxing without Flatpaks? Unless you are >>>> proposing a different sandboxing technology. >>> >>> Things like libvirt-sandbox have been around for a really long time >>> and don't require special packaging (in fact they work with any >>> arbitrary command). >> >> reading between the lines of the fine documentation, there is no mention >> of X11 or GUI applications, so i guess "arbitrary" is a bit of an >> exaggeration? > > It seems like it's not mentioned in the docs, but it does work as in > this example of running evince to view a suspect PDF file: > > https://honk.sigxcpu.org/con/More_sandboxing.html says: Note that the above example shares /tmp with the sandbox in order to give it access to the X11 socket. A better isolation can probably be achieved using xpra or xvnc but I haven't looked into this yet. so it doesn't actually sandbox very much, with access to the X11 socket the app can keylog and inject shell commands into terminal windows as much as it likes. > BTW libvirt sandbox allows either full-virt or container sandboxing. i'd hope if you don't use containers but full-virt it's going to use something more secure, like SPICE or something to display the GUI? but i'd call virtualization a bit of a heavy-weight approach. ... there's more prior art, the SELinux "sandbox -X", which at least starts a nested Xephyr for your convenience. http://danwalsh.livejournal.com/31146.html http://danwalsh.livejournal.com/31247.html these have in common that they're generally not very user friendly: you have to set up which files the program will have access to when you start it; also copy/paste probably doesn't work between the nested X server, which may or may not be a feature. FlatPak portals have the potential to be more user friendly since you can use the application's normal file picker to open files and the application only gets access to the file the user chooses. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
