Hey Kevin,
Thanks for your detailed response. I usually try not to read or write
long mails, but I made an exception this time. :)
On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx>
wrote:
Bastien Nocera wrote:
Why do we care about FHS compliance inside a Flatpak?
Because the proprietary directory layout means the applications (and
the
libraries!) have to be specially built for it, and in the worst case,
require code and/or build system changes to deal with it.
Yes, this is true. Sometimes minor changes to applications are required
to adjust paths. And sometimes it can be rather frustrating to debug
such issues when trying to package an app as a Flatpak. (Debugging
Flatpak apps is not easy.) So although we can automate most of the work
of creating the Flatpaks, only a human can make sure they're working
properly and fix problems when they're not.
And why would it be slower to release security fixes?
With system libraries, if there is a security issue in a library, the
library is updated by upstream, packaged, and delivered directly to
the
user.
With bundled libraries, if there is a security issue in a library, the
library is also updated by the library's upstream, but then the
bundle needs
to be rebuilt with the new library and the whole bundle has to be
delivered
to the user. The extra step of rebuilding the bundle (which typically
involves an additional maintainer) is what takes extra time.
Yes.
In the discussed approach where the Flatpak is composed from RPMs, the
library is updated by upstream, packaged, the Flatpak is rebuilt with
the
new library, and that is delivered to the user. So the extra step
happens
between the packaging of the library and the delivery to the user.
Maybe. I'm not sure about this. I believe the Flatpaks we're initially
planning to distribute will be composed from *Fedora* RPMs... not
upstream Flatpaks, at least not at first. So it should be possible to
build Fedora infrastructure for using Fedora RPMs as the basis for the
bundled libraries, and tracking them, and rebuilding affected Flatpaks
when there is a security problem. And stuff that's bundled frequently
enough could probably just go into the Fedora runtime.
In scenarios where Flatpaks are shipped by upstream, they will also
have to
rebuild the library in some way, or wait for their distribution to
update
the package. But in addition, most upstreams will probably just do
cumulative updates of the libraries when they do a new release of
their own
code (if at all!) and not do timely security updates at all.
There is also the efficiency issue of having to update the whole
bundle,
which will encourage cumulative updates and discourage quick security
updates. If the bundle is updated for every library security update,
there
will be a lot to download. People are already complaining about the
size of
Fedora updates as it stands, without having to update dozens of huge
bundles
whenever a commonly used library is updated.
And it is also not possible to just stuff all libraries into the
runtime to
avoid this issue, because then the runtime becomes a huge pile of
libraries
that the user may or may not actually use, and updating the runtime
(which
would have to be done the more frequently the more libraries it
contains)
becomes very inefficient due to its size.
Yes, these are all real disadvantages. And of course there is an
inherent trade-off in the decision to include more libraries in the
runtime. I think we'll probably want a fairly large runtime for Fedora,
though, to reduce the amount of stuff that has to be bundled in
Flatpaks. (I believe all updates are delta updates, so if only one part
of the runtime changes, the update shouldn't be too large.)
You forgot the positive changes such as:
- sandboxing
- dogfooding and testing for the sandboxing technologies
There ought to be better ways to sandbox applications than to turn
them into
what is essentially a full container (i.e., almost a full VM, only
minus the
kernel), bundling all the libraries. The split into an application
and a
runtime that Flatpak does is only a partial workaround.
I don't think there are better ways to sandbox applications. Sandboxing
is what has really sold me on Flatpak. The other main benefit of
Flatpaks is that independent application distribution becomes much
easier, which is very important for Fedora, but not at all a reason to
replace Fedora packages with Flatpaks. But sandboxing desktop
applications is a good reason to do so. We have the opportunity to
hugely improve the security of our operating system, and we should take
it. The benefits of this sandboxing outweigh the security costs of
increased library bundling. We will certainly have to be vigilant to
ensure Flatpaks are routinely updated when there is a security problem
in a bundled library, but if we are a little too slow, the sandbox will
often mitigate the problem. In effect, most successful exploits are now
going to require two different zero-days: one for the target
application, and one for the sandbox. That's huge.
We really need sandboxing technologies that work with shared system
libraries (also allowing the code segments to be shared in RAM). And
in
fact, we already have those technologies:
* Fedora ships and heavily promotes SELinux, which in fact, as far as
I
know, is also part of the sandboxing technologies Flatpak uses.
I kinda agree here (though I am a bit surprised, as I did not think you
were a very big SELinux fan). We absolutely could be investing more in
SELinux. But we have not been. Very few applications actually have
SELinux profiles, and they are all maintained downstream rather than
upstream. The volume of erroneous SELinux denials in Bugzilla is too
high, and the response time for fixing them too slow. SELinux profiles
work best when they are maintained upstream by application developers
who are familiar with SELinux, not by SELinux developers who are
unfamiliar with the application. But application developers who are
familiar with SELinux basically do not exist, and never will. So it
would be useful to have a general sandbox that works for the vast
majority of desktop apps.
* seccomp also looks very promising. Chromium (and QtWebEngine) is
already
using it effectively.
Yes and yes, both are true. But also: noooooo. seccomp is useful to
supplement a general purpose sandbox, but it's not suitable to be the
primary sandboxing mechanism. A secure, restrictive seccomp policy is
extremely, *extremely* brittle: if a library you depend on starts using
a new syscall, your application is going to crash. So it either
requires bundling libraries, or else never updating system libraries.
It is basically impossible to use them to construct an effective
restrictive sandbox unless it is highly targeted to a specific
application that bundles its dependencies and is maintained by a large
team of experienced developers. That's why it works well for Chromium.
(The team maintaining the Chromium sandbox is very good; they have gone
so far as to block calling syscalls with specific flags that they know
Chromium never uses, just to reduce the kernel attack surface.) I tried
a similar approach for WebKit a few years ago and quickly found it to
be completely unworkable; my favorite anecdote is how a Fedora update
to libxshmfence caused pages to not render anymore, because
libxshmfence started using a new syscall (it was memfd_create) that was
not whitelisted by the sandbox. We can't have that. Another anecdote
is the new seccomp sandbox for tracker-extract: whenever a GStreamer
plugin starts using a new unexpected syscall, or if you just happen to
have unexpected plugins installed, tracker-extract will crash. The
sandbox has to know everything about every possible GStreamer plugin
(so hope you never write your own custom one!). tracker is not the
greatest example here, because it is not an application, but my point
is that seccomp certainly cannot be used to construct a restrictive,
general-purpose sandbox, because applications are different and use
different syscalls. So if you're going to use seccomp as your primary
sandboxing mechanism, you'd better bundle all your libraries and not
allow any plugins. (I don't think you'd like that very much. ;)
Now, seccomp *is* very useful for just blocking off a few naughty
syscalls that applications have no business ever using. So yes, that's
promising. Flatpak actually already uses seccomp for this purpose. But
it's not a good choice to be our primary sandboxing mechanism.
Bundling libraries has many drawbacks, including security-related
ones (as I
explained above). (It also wastes download bandwidth, disk space, and
RAM.)
To really improve security, we must provide the benefits of sandboxing
without bundling libraries.
It's certainly a trade-off. I think the security benefit of the Flatpak
sandbox greatly outweighs the security cost of bundling libraries. But
I'm also worried that we might not develop tools for tracking outdated
bundled libraries in Flatpak applications. We'll need to.
Regarding bandwidth and disk space... I think we need to wait and see
and evaluate how things turn out. Certainly, if you have a bunch of
different Flatpak runtimes installed, there are going to be space costs
and bandwidth costs, and at a certain point that will be too
undesirable. So this is also a valid concern.
- more efficient update tracking than RPM (eg. no need to download
20 megs
of metadata to know there's nothing to update)
But less efficient updating, because you will need to download much
more
than 20 megs of bundled libraries. The only reason the metadata is
smaller
is because there is almost no dependency information encoded (only a
single
dependency on a runtime). But those dependencies are what makes
installing
and updating packages so efficient! Flatpak throws away the main
competitive
advantage of GNU/Linux!
Yes, but remember that Flatpak is only for desktop applications. The
majority of your OS is still going to be packages.
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
