Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/17/2017 03:14 PM, Neal Gompa wrote:
On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl <mstahl@xxxxxxxxxx> wrote:
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.
Portals themselves are orthogonal to the Flatpak distribution
mechanism. They can be used with regular applications too.



I read this like containers are something new and interesting. Upstream docker project started this effort a few years ago and the world has latched onto it. Fedora needs to adjust and become great at containers. Some of the interesting work we have been doing with atomic host, and atomic workstation is great. We don't have to continue to do things the way we have for 20 years. I believe Fedora needs to be at the forefront of figuring out these container issues. Flatpacks integration into the desktop gives us the potential of a great leap forwards in security. Imagine if Fedora finally fixes the biggest security issue of the desktop by running browsers in containers, in a truly secure manner with it fully integrated, not hacked up like it is in the SELinux Sandbox or by running docker images like Jess Frazelle was.

The stuff that flatpack is doing has been very good.

Colin Walters work on ostree and rpm-ostree is looking into how we can do offline updates already and yet this discussion is ignoring it. This stuff is great and it is currently controlled by Fedora we should be taking advantage of it. I run the atomic workstation now and am running flatpack, as well as development environments in containers. I feel some pain, but we are learning how to deal with it.

We need to learn to live with combinations of rpm packages, ostree distributions and containers running on Fedora.

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux