Re: F27 System Wide Change: Graphical Applications as Flatpaks

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@chello.at> 
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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org