On 15.06.2016 08:24, Florian Weimer wrote:
> On 06/15/2016 06:27 AM, Andrew Lutomirski wrote:
>> On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer <fwei...@redhat.com> wrote:
>>> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote:
>>>
>>>> I *strongly* disagree here. The xdg-app folks seem to be doing a
>>>> pretty good job with their sandbox. The kernel attack surface is
>>>> reduced considerably, as is the attack surface against the user via
>>>> ptrace and filesystem access. If Wayland is available (which is
>>>> should be!) then so is the attack surface against X.
>>>
>>>
>>> What about the direct access to DRI device nodes? Why isn't this a problem
>>> that reduces the effectiveness of the sandbox considerably?
>>
>> It's certainly a meaningful attack surface. That being said, if it
>> works well, it should be about as dangerous as Chromium's render
>> sandbox, and the latter seems to work fairly well in practice. I'm
>> assuming that xdg-app grants access to render nodes, not to the legacy
>> node.
>
> I'm not sure what kind of sandboxing there is. I was just able to open
> ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile
> (both outside the sandbox, obviously).
>
> I couldn't find any relevant device nodes in the file system namespace.
currently Flatpak doesn't have sandboxing enabled by default, since
substantial parts of the implementation of interfaces that allow the
applications to access resources outside the sandbox in a secure way
("Portals") are missing.
the design of the sandbox is documented here:
https://github.com/flatpak/flatpak/wiki/Sandbox
article about a sandboxed application (which doesn't need Portals):
https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
