On 07/17/2017 03:14 PM, Neal Gompa wrote:
On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl <mst...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
