On Wed, 2016-06-15 at 10:54 +0200, Michael Stahl wrote:
> 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 <fweimer@redhat.c
> > > om> 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/
I'll just note that making proper portals from a sandboxed environment,
so that they are both secure & don't hinder application functionality.
I've hit this in a negative way on an Ubuntu Touch running tablet -
they also use sandboxing for apps there, but apparently the open-file
portal can only handle a single file at a time. This basically breaks
any app that needs to work with many files at once - for example
viewing images from a uSD card you just inserted in an image viewer
application - you would have to open the images one at a time...
I'm sure this is something Flatpack can handle in a better way. :)
>
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
> .org
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
