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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
