
Flatpak – a security nightmare - stryk
http://flatkill.org/
======
vanderZwan
> _Sadly, it 's obvious Red Hat developers working on flatpak do not care
> about security, yet the self-proclaimed goal is to replace desktop
> application distribution - a cornerstone of linux security._

Sheesh, while the issues raised are all valid, this does not actually justify
such a conclusion about the intent of the Red Hat developers. Telling people
what their side of the story is for them in a dismissive fashion like this is
not going to make it more likely that they admit their mistakes.

A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human
cooperation (of any kind) more smoothly.

[0]
[https://en.wikipedia.org/wiki/Hanlon%27s_razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor)

~~~
kilburn
> A bit of Hanlon's Razor[0] goes a long way to resolve problems involving
> human cooperation (of any kind) more smoothly.

I don't like the snarky tone of the article, but I really thing you're being
naive here. Let's examine the facts:

\- Flatpak's intent is clear and stated first in in their homepage [1]:
"Flatpak is a next-generation technology for building and distributing desktop
applications on Linux"

\- Red Hat is _the_ company other companies hire to manage their linux
systems.

\- In the flatpak homepage there's a huge quote stating "The Fedora
Workstation team are very excited about Flatpak and the prospects it brings
for making the Linux desktop easier to develop for. We plan to continue
supporting this effort going forward."

\- The FAQ page states "We are explicitly using many features of the linux
kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that
Flatpak apps are running in." ... and then it turns out that they aren't, or
at least they aren't enforcing it.

I don't think this is stupidity. This is flat out lying to try and get
mindshare.

~~~
gbraad
Fedora and Red Hat are not the same thing. Sure, there is a relation between
the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion
in RHEL.

I just wonder why the author of this page does not disclose his name... And
even hides this from the whois info. This could have been written by a person
with a grudge for all I am concerned.

Sure, improvements might be needed, but haa the author tried to get this
happen in a different way, like a discussion? Creating a webpage and scream
fire is not the best approach in my opinion.

The issue raised about security updates for packaged apps is the same as for
container images and packages like .deb or .rpm in general. Generating a
runtime is a possible solution? Something like an automated way to regenrate
packages is needed, like flathub?!?

~~~
dpwm
> I just wonder why the author of this page does not disclose his name...

> And even hides this from the whois info.

The registrant country is listed as France and the registrar is OVH. They are
simply adhering to the GDPR. I have domains that have been like this since
May, even though I would be quite happy to have everything public.

> This could have been written by a person with a grudge for all I am
> concerned.

Your comment could have been written by somebody with a grudge against the
person you are claiming could have had a grudge for all I am concerned. A
vested interest can make a difference, but I don't really see how any of the
points are hard to verify.

Does this being written by a person with a grudge really negate the points
made?

\- Flatpak is claiming to be secure

\- Flatpak is sandboxing apps with full access to your home directory.

(What is the worst thing that an app can do? Nuke your home directory or run
malicious software. The sandboxing here does little to mitigate this.)

\- Apps are not being updated as quickly as their distribution repository
counterparts.

\- At some point in its past, a (presumably) privileged component with
permissions to setuid did not check that it wasn't blindly copying setuid.

It seems to me that this is more about easy delivery of software with a
security claim that is arguably pretty weak at the moment against likely
attack vectors. I can't see that changing without first thinking of what
you're actually sandboxing for.

There are already software delivery systems, such as 0install and appimage,
that do not make claims about being sandboxed and yet provide a similar (or
greater in the setuid case) level of security for the main threats.

I find it hard to understand who the project is for. If you're a developer on
your own machine then using your distro's package manager is probably more
secure. If you're a sysadmin, letting users use flatpak serves only to
increase the attack surface for privilege escalation.

~~~
toyg
The problem is that distro package managers are many and often complex to
satisfy, which is one of the reasons people don’t develop “real” desktop
software for Linux.

The new generation of installers (flatpak, snap etc) takes a cross-distro
approach that is supposed to result, more or less, in “package once, run
everywhere”: you build your app in a certain way and every distro should be
able to run it, regardless of package managers. It’s basically a way to
offload the compatibility headaches to flatpak developers and distribution
builders.

Obviously that approach works _only_ if flatpak _does_ actually get good
support in all distributions and becomes a de-facto standard, which is a
challenge because there are many competitors (Ubuntu Snap being the most
relevant one). If it remains just a glorified rpm (i.e. a redhat-specific
tool), then there is no point.

~~~
dpwm
> The problem is that distro package managers are many and often complex to
> satisfy, which is one of the reasons people don’t develop “real” desktop
> software for Linux.

If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted
"real" desktop software that Windows has become notorious for then I think we
may be better off without it. If you're talking about OSX, then I think you're
missing that it's a market skewed towards those with the money and will to pay
for proprietary software. Plenty of people are developing "real" desktop
software for Linux.

> The new generation of installers (flatpak, snap etc) takes a cross-distro
> approach that is supposed to result, more or less, in “package once, run
> everywhere”: you build your app in a certain way and every distro should be
> able to run it, regardless of package managers. It’s basically a way to
> offload the compatibility headaches to flatpak developers and distribution
> builders.

This isn't novel. 0install and AppImage have been around for a while now. What
is novel is that Flatpak combines this with sandboxing that doesn't really do
so much to mitigate against any vulnerabilities that aren't in the kernel. I
actually think they've got the sandboxing right, in that they are really
starting with minimum privileges and adding only what is needed.[0] The
problem, as they state, is that it is fine to drop all privileges for
something like a single-player game, but it sucks for a file manager. At least
according to their wiki, they're already doing most of what you could imagine
you could improve on the sandboxing. [0]

It's always this interaction with the outside world that breaks sandboxing.
It's rather easy to make a sandbox that runs as nobody and has no privileges
and no capabilities and no file access. It's a bit harder to make something
which has any of those things in a way which the user can grant sensible
permissions.

It sounds like in Portals [1] the Flatpak team have gone in pretty much the
only workable direction, although the Wiki is hopefully out of date and there
are more portals. The problem they will have found is that to package anything
useful and get feedback and validation requires that they implement the most
difficult bits first. So I suspect the situation is "secure file picker is
coming".

Sandboxing is a lot of work, not in the closing down but in the opening up.
One of the more innovative approaches is to be found in Sandstorm [2].
Although marketed as a way to run web applications on your own server easily,
it is actually a tight sandbox built on top of Cap'n Proto, which means that
E-style capability-based RPC is intrinsic.

Sandboxed apps have no access to anything, cutting down on kernel attack
space. The only connection to the outside world is through a UNIX socket file
descriptor opened by the supervisor. The capabilities-based security model
mean that a sandboxed app could request the ability to connect to
"drive.google.com", or even a specific URL. This could also be passed to other
apps through the supervisor, subject to user approval. Capabilities can be
stored on disk to be later restored from the supervisor.

In Sandstorm the UI for granting capabilities between apps is working, but
progress has slowed as the team have all had to find other ways to pay the
bills.

> Obviously that approach works only if flatpak does actually get good support
> in all distributions and becomes a de-facto standard, which is a challenge
> because there are many competitors (Ubuntu Snap being the most relevant
> one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then
> there is no point.

I think the problem is that if your target is casual users, they're not going
to necessarily understand the nuances and limitations of the sandboxing.

[0]
[https://github.com/flatpak/flatpak/wiki/Sandbox](https://github.com/flatpak/flatpak/wiki/Sandbox)

[1]
[https://github.com/flatpak/flatpak/wiki/Portals](https://github.com/flatpak/flatpak/wiki/Portals)

[2] [https://sandstorm.io/how-it-works#capabilities](https://sandstorm.io/how-
it-works#capabilities)

~~~
TimJYoung
"If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted
"real" desktop software that Windows has become notorious for then I think we
may be better off without it."

You're ignoring a huge amount of business software that is created for, and
runs on, Windows. That's like judging Android or iOS based upon the consumer
crapware that gets sold/given away in their app stores, as opposed to the many
business apps that are used to automate and improve all sorts of tasks on
mobile devices.

I keep seeing this pattern repeated over and over again: someone (this has
been me, several times) mentions on HN that Linux needs a better way to allow
for binaries to be dropped on a system and run without requiring re-
compilation or overly-complicated containers/sandboxes, and the answers
invariably end up being "don't want it, don't care". But, the reality is that
there _are_ a very large number of people that would jump to Linux in a
heartbeat if they could target the OS for distribution in that fashion. It
just seems like a bunch of ideology run amok with zero thought given to the
actual needs of professional developers/companies. And, there's a lot of
evidence that this is one of the primary things holding back Linux adoption on
the desktop.

The rest of your reply was very informative, thanks.

~~~
dpwm
> You're ignoring a huge amount of business software that is created for, and
> runs on, Windows. That's like judging Android or iOS based upon the consumer
> crapware that gets sold/given away in their app stores, as opposed to the
> many business apps that are used to automate and improve all sorts of tasks
> on mobile devices.

Thanks for this. Indeed I was responding a bit flippantly to the whole "real"
desktop software, as if there isn't any on Linux. I appreciate now it probably
wasn't meant in that way, and so that aspect of my response was flippant and
unhelpful.

Indeed, it seems for every example we find of serious expensive proprietary
software that runs on Linux, there is another that doesn't.

We have Maya running on Linux, and Softimage. Both sold by Autodesk (albeit
acquired). And yet other Autodesk products, like 3dsmax and Autocad, do not
have Linux support. Asking about this on their forums appears to result in a
rather curt response to read the system requirements where it says "Windows."

These are tools that people learn and take with them between jobs, and I can
well imagine that these are people that could work on desktop Linux without
too many problems as long as those tools moved with them. Replying "but
blender can do that!" is completely ignoring the reality that people have
invested significant time into these tools and know them well. Whilst blender
is an amazing piece of free software, it's by no means an industry standard.
In the way that Gimp is quite phenomenal, it seems many professionals find it
lacks features that Photoshop has.

I don't think the "web browser" response cuts it in other areas either, even
if a lot of the less technically demanding software is going cloud-based.

> It just seems like a bunch of ideology run amok with zero thought given to
> the actual needs of professional developers/companies. And, there's a lot of
> evidence that this is one of the primary things holding back Linux adoption
> on the desktop.

I think you're right, and I'm probably in that category. I've also seen what
bad vendors can do to an ecosystem though. The windows ecosystem is still full
of dodgy vendors.

I'm quite convinced that package-once-with-sandboxing will happen, and I will
admit that Flatpak is probably in a prime position for that to happen. I think
they've probably got the most correct direction of all the attempts in the
space, it just doesn't seem to be there yet.

From a commercial vendor point of view, it's also not a problem if the user's
home directory is bind mounted and over a year ago there was a bug with the
sand-boxing that let malicious vendors install software that could run as
root. Let's not forget that most Windows apps don't go anywhere near a sandbox
in the first place and their installers need system-wide access. There's
plenty of low-hanging fruit still in this space.

Things have definitely got better in recent years. One of the biggest things
to improve this is that 32-bit x86 is dying off. There were a number of
vendors that did the "we can just build 32-bit, like windows" without
realising or caring about the horrors of multi-arch dependency hunting that
they were inflicting on the sysadmin.

So thank you for your comment. It made me realise that I was probably being
quite flippant about software which does fulfil a niche need and does it well,
and that you only need one piece of such software to tie someone to an
operating system they may otherwise have no affinity for.

~~~
TimJYoung
Thanks for the thoughtful comments, they are very much appreciated.

The thing that a lot of Linux developers don't seem to get about Windows is
that its binary distribution model is an opportunity/productivity multiplier,
and it all hinges on three major points:

1) Backward-compatibility is real, and, contrary to what most people say about
MS/Windows, this is _very_ pro-consumer. Just chucking code at people and
saying "but, you can just re-compile it" ignores a lot of realities, including
the fact that even developers don't want to be forced to recompile binaries
that they are not, themselves, working on as their actual work.

2) You can deploy 32-bit binaries on 64-bit systems and they work just fine.
It really made the switch to 64-bit versions of Windows a non-event, whereas
this is another issue that developers need to worry about when targeting
Linux. And, there are a _lot_ of applications that simply don't benefit from
being 64-bit because they don't need, or can't use, the increased address
space, so forcing developers to specifically target 64-bit is just another
unnecessary hurdle.

3) You can actually create binaries for Windows that don't require any
dependencies other than what is available in the OS. This means that you can
create binaries that work on tablets, laptops, desktops, and servers without
recompilation. This also ties in to your comment about the installers, but the
reality is that you really only need admin access for an installer to put
things into the "Program Files" folder tree, or to install services. Apart
from that, most professional software doesn't touch anything other than the
user-specific folders (if Windows doesn't delete them first ;-) ).

I don't think that this point can be overstated: if you create a neutral OS
platform where desktop developers can deploy their software with minimal fuss
and no gatekeepers, you will win the desktop space, period. More than anything
else, desktop developers want to make money, and an open OS that does its
thing and stays out of the way is the ticket to that money. But, in order to
do this, a lot of current Linux developers will need to get used to sharing
Linux with commercial vendors and proprietary software, and I think that's
still a hard sell. And, unfortunately, a large part of that mindset is wedded
to this bizarre idea that desktop developers like Windows because of Windows.
Desktop developers like Windows because a) that's where the users are, and b)
they can make money without being forced or required to expose their source
code. If the same can be done with Linux, then Linux will have no problem
taking the OS space away from MS completely.

Linux is stuck in "server/appliance mode" right now, and it's a shame because
if there was ever a time for Linux to take over the desktop, it's now. As you
say, web applications are just not a suitable replacement for all desktop
applications. MS keeps trying to lock down how development is done on Windows
and, if they succeed, then everything that I stated above will go away and
there will be a lot of developers looking for a new home. Any OS that starts
out with "you can only use our development tools/languages, and no others", is
going to whither away and die. It happened to Apple once, it appears to be
happening to Apple again, and MS has apparently decided that it should emulate
Apple. The whole reason why Windows became popular in the first place was
because there were a ton of development tools/compilers/languages that could
be used to produce binaries for Windows, and Windows gave zero preference to
any of them. This was carried over from MS-DOS. And, _none_ of this precluded
_any_ vendor from going ahead and providing/selling their source code along
with the product. Linux developers have just got to let go of trying to
control how people use the OS, and just try to make it as amenable to as many
usage/deployment scenarios as possible.

------
dralley
Cross-posting a comment from Reddit, because it nails one of the points
mentioned:

\---

The list on the page is

    
    
        Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ...
    

With the exception of Steam all of those programs are used to open random
files anywhere on the system. One could implement a permission prompt for
accessing a file, but that would lead to a Vista-like Situation where
basically every action causes a prompt.

Now, that's not to say this is good as it is, but for most listed programs
it's probably the way to go.

~~~
gmueckl
This highlights a conceptual dilemma with access rights in file systems: if an
image manipulation software wants to open .bashrc, this is potentially
suspicious. But for a text editor this is probably ok. Likewise, a text editor
that reads a binary executable is probably a little bit fishy. But a unzip
program might so that for a valid reason (e.g. ZIP archive appended at end of
program, a common thing for installers). How can we distinguish between those
cases?

~~~
briffle
This is pretty much the whole point of SELinux (and probably AppArmour)

~~~
geofft
How does SELinux or AppArmor distinguish between those cases? More
interestingly, how can it tell that VSCode spontaneously editing .bashrc is
bad, but doing so in response to user input is good?

(There are capability-based systems that permit distinguishing between these
cases, but to my knowledge SELinux and AppArmor don't support this.)

~~~
cyphar
SELinux and AppArmor would allow you to specify that your text editor is
allowed to edit .bashrc, but some random other program isn't.

But I agree with you that this is not really a useful security feature --
you'd want something where a program has to be explicitly granted permission
rather than some programs being able to do things that others can't (because
then any attacker will just spawn "vi -c 'bad payload'" to get around the
restriction).

------
gbraad
The developers are employed by Red Hat, but that does not make this a Red Hat
endorsed product. It is not included in the current offering of RHEL and
unlikely would be in a new(er) version as the technology is immature/not well
enough tests d/proven yet for inclusion within EL. I call the usage of 'Red
Hat' here clickbait and sensationalism as there is no indication within the
text that shows the aforementioned non-existence of endorsement or inclusion.

Note: the engineers working on Flatpak and both friends and colleagues of
mine. Just concerned that the author misrepresents our employers viewpoint. We
are allowed to work on side projects, but that does not make them default
inclusions or endorsed.

------
nickysielicki
1\. None of this has anything to do with Flatpak, it has everything to do with
Flathub and how particular software is packaged.

2\. Your preferred distribution can host their own Flatpak repository and
ensure that things like security updates get dealt with properly. Flatpak is
not Flathub.

3\. This ecosystem is growing, so it's putting some things on the backburner,
prioritizing application availability over holding a package to make sure that
permissions are perfect. There is no reason that these issues can't be ironed
out going forward.

~~~
aritmo
But Flathub is flatpak. Also, does flatpak have the full support of redhat?

~~~
Natela
No. Flathub has nothing to do with flatpak technology itself. Flathub is just
one server hosting some flatpack repos.

It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many
other you could add to get your apps

~~~
int_19h
Isn't the whole point of Flatpak to prevent the same app from being packaged
multiple times for different distros?

~~~
Natela
Ideally , Firefox would be downloaded from official Mozilla Flatpak repo,
Blender from Blender Flatpak repo on Blender server, etc... And we would have
this list of those repo on our distro.

However because the official adoption is slow (very few software have official
flatpak repo), flathub allowed the community to build packages themselves. But
this is clearly not how it should be.

The second (more legit) reason of flathub is that small developer might not
want to pay a server to host their app and flathub proposes to host their
repo.

------
djsumdog
Ugh. This trade off again. Linux package management means you update a library
once, and fix that security problem everywhere for all the apps that use that
library .. except for Firefox, Libreoffice, Chrome and others which insist on
packaging their own versions of libjpeg, libpng and everything under the sun
for stability.

A docker container contains all its own dependencies too. You gain stability
.. but you could have a bedbug nest of security problems down there.

I don't get the move to Flatpack and Snap for desktop apps. Desktop apps need
to interact with the base OS, the display system (X11 or Wayland) the shared
toolkit libraries (GTK/QT). I've screenshots of native vs Flatpack vs Snap and
they tend to have different window borders, some get the GTK themes matched up
while others don't.

Not to mention the wasted space when every single application has its own
version of everything. What, did you think electron apps each packaging their
own 80MB web browser was a good idea too?

This just seems like the wrong direction to move in for Linux. We're not
MacOS! We don't have hacked together shit like Android apks. We need to be
better than that!

~~~
XorNot
Linux needs a deduplicating filesystem though in the kernel. Something to make
containers and docker handle the situation of "lots of mostly identical files"
well. Even ZFS, which should be good at this, really isn't.

~~~
dralley
Take a look at Fedora Silverblue with rpm-ostree, it does basically what you
describe

------
wbond
> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode,
> Android Studio and Sublime Text still use unpatched git version 2.9.3.

Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and
no version of Sublime Text comes with git.

After such inaccurate information, I can’t help but question the rest of the
article.

~~~
v8engine
I don't know about git integration but as for Flatpak version of Sublime Text,
I found this:

[https://flathub.org/apps/details/com.sublimetext.three](https://flathub.org/apps/details/com.sublimetext.three)

~~~
wbond
Yes, it appears that the flathub maintainers have published Sublime Text under
flathub. This is not an official distribution channel by us, and looking at
the spec
([https://github.com/flathub/com.sublimetext.three/blob/master...](https://github.com/flathub/com.sublimetext.three/blob/master/com.sublimetext.three.json))
it seems to rather automatically install Package Control, but also in a rather
brittle way. Sigh.

~~~
nickik
If many distros and people want to use a flatpak to install software even with
these drawbacks that would be a good indication that it would be worth doing
upstream.

~~~
wbond
We currently provide a full complement of Linux package manager repositories,
along with tarballs:
[https://www.sublimetext.com/docs/3/linux_repositories.html](https://www.sublimetext.com/docs/3/linux_repositories.html).

~~~
vetinari
Have a look into flatpak too, otherwise in the not-so-distant future the users
could have a problem.

For Fedora, they are planning switching to Silverblue around Fedora 30 (atomic
system, rpms still supported, but jumping around the hoops).

~~~
wbond
It will be interesting to see if Flatpak, Snap or AppImage ends up being the
predominant force in the new wave of Linux packaging. Knowing Linux, users
will probably expect projects to support all three. :-)

------
phaer
Could someone knowledgeable enough comment on how this compares to Cannoicals
Snappy
[https://en.wikipedia.org/wiki/Snappy_(package_manager)](https://en.wikipedia.org/wiki/Snappy_\(package_manager\))?

~~~
linappdev
With the exception of snaps running on Ubuntu and Solus, snap confinement is
limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able
to offer full confinement, currently. Solus imports these changes into their
kernel, though I don't trust the changes much because they haven't undergone
formal review and have been approved by the kernel developers.

So, for example, on Fedora, Debian, CentOS, or openSUSE, snaps run in
"devmode" because of the missing functionality. There's been some work over
the last couple of years to upstream some of the work on AppArmor (so openSUSE
may partially work in the future). There's a desire to support SELinux
properly, but to date, no work has been done. There is an SELinux policy that
attempts to confine snapd itself, which was contributed by the guy working on
the Fedora/CentOS package for snapd (though it looks like the policy would
also work for openSUSE and Debian SELinux setups, too).

Based on conversations I've had with the Snappy team before, it comes down to
two things:

* Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to * Canonical's customers haven't demanded it of them yet

I find the latter point especially strange given the constant demand for
official Snappy support on CentOS and Amazon Linux 2 (which is currently not
available yet). Both distributions have SELinux and rely on it for security.

In addition, the majority of snaps are not sandboxed at all anyway, as they
operate in "classic" confinement. That is, they're not confined, and have full
access to the system, they just use snapd as the delivery system for the
software. So _even_ if Snappy confinement actually worked on all Linux
distributions, it doesn't matter because most apps delivered through Snappy
are entirely unconfined.

Finally, Canonical is the sole arbiter of snaps. You cannot use your own store
with it, as snapd is hardwired to Canonical's store. They own all the
namespaces, and are the sole publisher. And yet, they have a confusing policy
of how they don't consider themselves the distributor of software when they
are... It's strange. But because you can't run your own store, you're at their
mercy for snap names, available functionality, and so on.

Flatpak, in contrast, is designed to offer the fullest confinement possible
with common security features in the mainline Linux kernel that all major
distributions offer. Applications register what they need in their manifests,
and the Flatpak system handles granting access as appropriate. Flatpak relies
on federation through "portals" for interacting with the host environment, and
that allows for the applications to have far less direct access than they
would normally have. It's basically an Android-like setup, and it seems to
work well, though it's still far too coarse for some kinds of applications.

Flatpak lets you run your own repository, so you can implement whatever means
you'd like for delivering them, even keyed paywall locations, so that
customers who pay get their own access to their own purchases. But most apps
probably should be pushed to Flathub, especially if they're free. I think no
one has figured out yet how to do paid stuff.

(Disclaimer: I'm a Linux app developer that grudgingly deals with both
formats. I'd rather just keep using RPMs myself, as it works well and is
reasonably portable.)

~~~
niemeyer
> Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to
> offer full confinement,

The AppArmor patches have been largely upstreamed by Canonical, and
improvements continue to float upstream constantly. So claiming it's not being
reviewed isn't accurate.

> * Canonical doesn't know how to work with SELinux at all, and doesn't want
> to learn how to

That's disingenuous. Canonical works with many parties, and has people working
on LSM stacking for example precisely to support co-existence of the systems.
We also had exchanges in the forum to discuss the implementation of actual
backends in snapd to support it, but Canonical indeed won't pay for the cost
of implementation until there's a reason to do it. That's business as usual
and pretty straightforward.

> In addition, the majority of snaps are not sandboxed at all anyway, as they
> operate in "classic" confinement.

That's incorrect by a huge margin. I'm curious about where you could possibly
have based that opinion on? Classic snaps require manual reviews, which need
to be backed by public justification. You can see every single request
floating by in the store category at
[https://forum.snapcraft.io](https://forum.snapcraft.io). That means every
snap people push without talking to anyone are not classic, and thus the vast
majority.

> Finally, Canonical is the sole arbiter of snaps.

Well, yes, it has created the project and maintains it actively for years now.
You're welcome as a contributor.

> Disclaimer: I'm a Linux app developer that grudgingly deals with both
> formats. I'd rather just keep using RPMs myself

And I work on snapd (and have also worked on RPM back then, so enjoy :).

~~~
bubblethink
>Well, yes, it has created the project and maintains it actively for years
now. You're welcome as a contributor.

So, there cannot be a third-party/self-hosted snap store ? That seems like a
major limitation.

~~~
niemeyer
There are self-hosted proxies, and there are publicly hosted stores, but all
stores are part of the exact same hierarchy and share some of their knowledge.
That's mainly a consequence of implementing the intended user experience as
originally designed back then.

------
Ecco
Wait a minute, did somebody get so pissed at flatpak that they bought a domain
name just to specifically host that single blog post?

~~~
TeMPOraL
Domains are cheap. Often free for one year.

~~~
Ecco
Well they’re “free” if you buy them alongside hosting. Still even if cheap,
that’s quite a commitment: finding a domain, paying it, writing a custom
(albeit simple) website, uploading it, etc...

~~~
TeMPOraL
> _Well they’re “free” if you buy them alongside hosting._

Depends on hosting company. I've "bought" domains for free many times, without
hosting, just to run joke sites for few months.

~~~
Ecco
Ha, interesting! I always assumed a .org was at least a dollar. Mind sharing a
link?

~~~
TeMPOraL
Don't have a free "org" source; maybe they never was. Free domains I got were
under national TLD.

------
andreyv
Flatpak, Snap, container images are the new iteration of static linking.

Just like with static binaries, they make deployment easier for the developer,
but introduce problems with size, duplication and library updates.

Flatpak added runtimes [1] to alleviate the problem. Does this solution look
familiar? Yes, it is the same dynamic library concept. We are coming full
circle.

[1] [http://docs.flatpak.org/en/latest/available-
runtimes.html](http://docs.flatpak.org/en/latest/available-runtimes.html)

------
jbk
> VLC [...] filesystem=host

See my comment on why it's not easy to fully sandbox software like VLC:
[https://news.ycombinator.com/item?id=14409234](https://news.ycombinator.com/item?id=14409234)

The author is correct, in the fact that flatpak-vlc is not a secure sandbox.

~~~
laurent123456
Thanks for sharing the info. I'm just curious - how would splitting VLC into
multi processes solve the permission issue, since the sub-processes will still
need access anyway?

~~~
jbk
Each subprocess would only get one permission, the one that it actually need.
The critical parts (audio decoders, video decoders, parsers) would not get
access to $HOME or network, for example.

~~~
laurent123456
Thanks, that makes sense.

------
emmelaich
By default, flatpaks don't have r/w to your home.

And setuid binaries have been blocked for a while (as the article says). Plus,
selinux will have these things locked down on a system that uses selinux.

I think the problem is part perception. Flatpak, like Docker is not primarily
for security isolation. It's isolation for ease of deployment - to avoid
dependency hell.

Not saying Flatpak's failings are not a problem. Just keep some perspective.

------
ktpsns
To be honest, this security nightmare also covers other contemporary
"container" formats such as docker.

Running docker containers as a non-root user is unfortunately still not a
widespread practice. That means that any root process within a docker
container has root on the host.

~~~
viraptor
Only if you run with no isolation / user namespace. And even without that, you
need to run with `--privileged` to get access to interesting capabilities.
It's not as simple as container root == host root.

~~~
yrro
Are user namespaces enabled by default, or are they something that you have to
enable and then spend time dealing with all the containers that weren't
written with them in mind?

------
RX14
What a lot of people are missing is that flatpaks put the flatpak author
responsible for the security of every package inside the flatpak. If you use a
package from an unofficial rpm or deb repo, they're nearly always still
dynamically linked, so security updates for things like openssl still apply.

~~~
linuxftw
> they're nearly always still dynamically linked, so security updates for
> things like openssl still apply.

Could be, or might not be. It's easy enough to ship compiled libraries in the
same rpm/deb as the software you ship, or put your defunct versions into the
same unofficial repo under a different name and have your application pull
from there. In fact, they might not use openssl at all, possibly some other
half-baked library. Of course, that's for languages that are compiled; people
can vendor in all sorts of stuff into python sources. Don't even get me
started on golang.

Installing software from any source involves risk. Distribution repos help
mitigate some of that risk. Flatpaks as a technology don't change the risk
(significantly) from a bit-rot point of view IMO.

~~~
cyphar
> Distribution repos help mitigate some of that risk. Flatpaks as a technology
> don't change the risk (significantly) from a bit-rot point of view IMO.

I don't agree. There was a FOSDEM talk by one of my colleagues specifically
about this issue, and why Flatpak is walking us backwards in terms of how
packaging has worked historically[1]. Distributions are far from perfect
(hell, some of them ship my packages and I'm definitely far from perfect) but
they do solve real problems and going to a Windows-DLL-dump method of
packaging is going in reverse.

If your "package format" makes developers maintain all of their dependencies,
it isn't solving the problem that most people actually want you to solve -- to
be able to do less work and build on top of other people's work. By using
dependencies maintained by your distribution you also get security updates and
maintenance for free -- many distributions have paid security and maintenance
teams that deal with precisely this. I cannot overstate how much work it is to
maintain your own distribution.

[1]:
[https://www.youtube.com/watch?v=mkXseJLxFkY](https://www.youtube.com/watch?v=mkXseJLxFkY)

~~~
linuxftw
I'm with you, I prefer traditional packaging over flatpak. I usually build
from source if I need a newer version than what a distro provides (or if the
distro doesn't provide it at all).

------
newnewpdro
This is what happens when you try escape "dependency hell" by turning the host
into a composition of hosts-per-application.

Now you have a clusterfuck of dependency islands which all need updating and
have their own unique sets of CVEs and upstream release schedules and
policies.

It's not really flatpak-specific, this is the reality of containers (in the
image/rootfs software distribution sense, not namespaces+cgroups) in general.

------
nickik
Flatpak and Flathub are not hiding this and nowhere on Flathub does it claim
that all Flathub apps are securely sand boxed. Flathub has unoffical packages
and this it has the same issue like all other unoffical repos.

Flatpak CAN be used to do sandboxing, but that totally different from saying
'all application will be securely sandboxed'. I don't know where the authors
got this idea from.

The simple fact is, that sandboxing on a legacy system is difficult and
Flatpak can't magic away many of the security issues in the Linux desktop.

Also all the 'Red-Hat Developers' evil reminds me of the typical Systemd-hate
rant and I really hope we don't have to suffer another iteration of this in
the Open-Source community. The person that leads the project works for Red
Hat, but its not a Red Hat project.

------
pdonis
I share this writer's concerns with Flatpak. It looks to me like yet another
attempt to bring the horribly broken and insecure "download it and drag it to
your desktop" model of application distribution, which has long been a source
of viruses and malware on Windows and Macs, to Linux.

~~~
stephenr
> bring the horribly broken and insecure "download it and drag it to your
> desktop" model of application distribution, which has long been a source of
> viruses and malware on Windows and Macs, to Linux.

Wat?

Windows _famously_ doesn’t have “just drag it to your desktop” to install.
There’s an entire segment of the industry around building installers and
managers for installation of windows programs.

And I can’t recall a single mac-affecting malware that spread the way you
describe _except_ maliciously modified versions of pirated commercial software
(eg adobe stuff) which doesn’t actually install via drag and drop anyway - it
has an “installer” if its own.

~~~
ambrice
I think the reference is to the fact that on Windows you download some random
.exe installer from some place on the internet and trust it, rather than
selecting a signed package from a trusted repository that gets automatically
updated. Should have been "download it, drag it to your desktop, and install
it".

~~~
pdonis
Yes, this is what I was referring to. Sorry for my unclear phrasing.

------
Natela
The sandbox is in a sense working, the problem is that the folder the app
accesses is more critical than what the user thought. We should make sure
nothing in home will get executed : no bashrc, no scripts, no executable. In
the "ideal" world you would never download & run any script or any executable
(like on Android or IOS). Everything the user should be able to do is install
or run flatpak apps.

(Of course in practice as soon as you are programming a bit you'll want to
open a terminal, run scripts and do stuff outside flatpak)

For the second point, well it's just that update are not frequent enough ?
This has nothing to do with flatpak technology right ?

~~~
dcbadacd
Maybe it's about time we break backwards compatibility and get rid of all
dotfiles in ~ and move them to say .local/share/software_name and then start
restricting access to those folders?

~~~
mort96
But I still want to be able to use my Flatpak VsCode to edit config files in
.local or .config, and I still want to use my Flatpak Gimp to edit images in
.local/share/icons.

~~~
dcbadacd
The chances of those things happening are rather low for the average user a
prompt would solve those and would be a way better solution that just allowing
full access to ~ and any dotfiles.

~~~
bil-elmoussaoui
There are a WIP portals that would instead of giving access to the whole
filesystem or the whole devices list a prompt for the user to allow access to
a specific device or a specific system feature. Let's take for example a Music
player, you can give it access to `xdg-music` folder only. But the users will
start complaining about the fact their music is stored somewhere else and they
would want a full access to their home folder or to the devices list to play
music from an external hard drive or whatever. Things are not perfect yeah,
but many of those apps were not made with a sandboxed env in mind. There are a
bunch of new apps that were created with that in mind and use those portals
features. Things are getting better, slowly maybe but surely! The Flatpak
packages will improve with time and we will be getting a better way of
distributing apps safely and easily on Linux.

------
bubblethink
I don't see any real benefits to using flatpak in its current form. You get
worse integration with the rest of the system, poor tools that are inferior to
your system's package manager, and no real security benefits currently. What's
the point of launching all these rubbish proprietary apps on the store with no
real sandboxing ? It creates a false sense of security, which is worse. All
the proprietary apps will do what they used to. They've just been ported to
flatpak as thin wrappers. If you get the dropbox flatpak, it will continue to
litter your home directory with hidden files.

~~~
androidgirl
I use flatpak on my system for the fact that packages can be had there I can't
get through my package manager easily and officially. That's the only selling
point!

~~~
bubblethink
Yes, that's kind of true. You can get newer versions of things slightly
easier. It can be major point if your distro is getting quite old (like RHEL
or even xenial), but if you keep up with a 2 year cycle of distro updates like
ubuntu LTS, you rarely hit that scenario.

~~~
androidgirl
That's definitely true! It's also good for smaller distros with smaller
package managers. It's easier for a dev team to support just Flatpak than to
bundle/petition for pacman, apt, yum, eopkg, and so on.

I'd greatly prefer 'native' packages though.

------
jopsen
flatpak is still early.. most apps are still installed from package managers,
and few apps are written with flatpak in mind.

The current situation is probably not much worse than installing from various
third party package archives.

I suspect things will get better as adopting catches on.. it's no surprise
that early stage open source software have rough edges.

------
p2t2p
Trust me, nobody cares. The regular user doesn't go past "I can install
Spotify in one click". It always were like that and it always will be like
that. With more "normies" coming to Linux there will be more stuff like that.
That is exactly why people were saying that there are no viruses on Linux only
thanks to lower popularity.

And with all honesty - how many of us read script files when installing
something from AUR?

But hey, nobody forces you to use it! You can always choose you distro repo or
go DIY way.

~~~
p2t2p
Downvoted without replies... Does anybody find statement that most users don’t
spend too much time to ensure security of their machine offensive or
incorrect? I know only myself and few other fairly geeky people doing that...

------
anon_cow1111
Random mint 18.04 user here.

I just noticed about a week ago that flatpak was downloading huge amounts of
data (like hundreds of MBs). I had all system updates set to download and
install manually, and hadn't installed anything new for at least a month. All
this data was getting sent to /var/tmp as flatpak-cache folders.

I don't know what it was doing but I've since turned it off in the startup
list. Any ideas? What are the chances this was malicious?

~~~
c487bd62
I'm not a flatpaker but maybe it was updating the runtimes?
[http://docs.flatpak.org/en/latest/available-
runtimes.html](http://docs.flatpak.org/en/latest/available-runtimes.html)

Honestly I would be more worried about running mint (a topic not suited for
this thread, a quick search would probably show you what I've read about it in
the past).

------
megous
What's cross-platform experience for packagers/builders? Seems like you can't
do cross-compilation, so expecting upstream to provide flatpaks for users is
expecting upstream to manage virtual or real machines for every [desired] CPU
architecture with all the annoying host distro installation/management,
networking stuff, etc.?

At least with the current model, upstream developers can offload most of that
to distribution packagers.

~~~
wmf
In reality every desired CPU architecture is x86-64.

~~~
megous
I have GNU/Linux desktops on armv7 and aarch64, and i686 laptop. So with this
attitude, flatpak is mostly worthless to me.

------
patal
> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to
> this vulnerability. Flatpak developers consider this a minor security issue.

The flatpak release notes talk of a "minor security update", where "minor"
surely means "of small size", not "of little importance" as OP would have it.
Though the text could add a little importance.

------
jwildeboer
Disclaimer: I work for Red Hat

I strongly oppose these kind of attacks by people hiding their identity. No
matter how valid the criticism might be, this goes against all the ethics of
Open Source.

Just like the Devuan folks that vigorously attacked systemd and Lennart.

This must not be tolerated.

Yes, I’m very upset.

~~~
JepZ
Why is it problematic when people hide their identity? I mean, if the
criticism is valid, what does it matter who said it?

I think hiding the identity is not the real problem here. To me, it looks more
problematic, that the critique is not very constructive, one-sided and loaded
with imputations.

~~~
jwildeboer
> I think hiding the identity is not the real problem here. To me, it looks
> more problematic, that the critique is not very constructive, one-sided and
> loaded with imputations.

And I think there is a strong correlation between those two things.

It definitely makes it impossible to enter in a productive discussion about
how flatpak could work better. The way it stands now, this rant is useless,
aimed to be destructive and simply unacceptable. IMHO.

~~~
folknor
> And I think there is a strong correlation between those two things.

There might be a correlation between those in this case.

But just because it - perhaps (I haven't actually read the "article") -
applies in this case, that's a far cry from being a general rule.

Think of it in terms of - for example - a muslim speaking up against
oppression in their home country, or a Tibetan speaking up against China.
Should they not be allowed to do so anonymously?

It is possible in most cases to judge merit on content/argument alone.

It's very difficult to imply or deduce someones motive, whether you know who
they are or not. In most cases, you would be mistaken.

I find it helpful to remind myself that most people do what they do out of
love, even if their actions are/seem utterly insane, or are/seem destructive.

------
glglwty
Is the sandboxing of flatpak more or less secure than docker?

~~~
lvh
They use a lot of similar techniques. One big difference is that docker uses
user namespaces and flatpak does not. I'n not sure about the reasoning, but
it's probably a combo of "not trusting user namespaces" (disagree) and user
namespaces requiring privileges to use.

It sounds like the bigger issue isn't that the underlying technologies are
fundamentally better or worse, but that the de facto configurations are worse.
In particular, the median docker container can not write to my home directory.
The median flatpak can.

Despite the ordering, the "no updates" seems like a way worse issue than the
"most of the sandboxing is ineffective". It seems pretty clear to me that a
lot of apps need wide access and the first person who does a great job at that
will do us all a big security favor but we're not there yet in terms of UX.
Sometimes I really want my text editor to edit my bashrc. Maybe that should
require a privilege escalation, that's fine.

~~~
Jasper_
Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview
here:
[https://github.com/projectatomic/bubblewrap/blob/master/READ...](https://github.com/projectatomic/bubblewrap/blob/master/README.md#user-
namespaces)

There is nothing against Flatpak using user namepsaces when the developers
feel a bit more comfortable with that, though.

~~~
lvh
Are you one of the developers/speaking for them? That warning is pretty old.

~~~
cyphar
Creation of user namespaces still has caused security vulnerabilities in very
recent history. But with seccomp you can disable it inside a container (which
is what Docker and LXC do by default for instance), and it doesn't make sense
to be worried about that _as a container runtime_ because you are using it to
increase the security of your sandbox.

------
codedokode
> Almost all popular applications on flathub come with filesystem=host,
> filesystem=home or device=all permissions

Aren't other sandboxes (like Ubuntu's Snap) the same?

~~~
ianlevesque
Not on macOS.

------
tomc1985
Coming out with yet another deployment format and then expecting maintainers
to include you is wishful thinking

------
zeroname
_" Almost all popular applications on flathub come with filesystem=host,
filesystem=home or device=all permissions, that is, write permissions to the
user home directory (and more), this effectively means that all it takes to
"escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's
it."_

No shit, installed applications can write to the filesystem. What an
exceptional security hole that only affects flatpak and literally every other
form of installing those same programs outside of a sandbox.

~~~
alkonaut
A document editor will want to write to the users documents directory.

Is the problem here that the user home dir both contains typical locations for
user data _and_ writing files with certain names to it will automatically
execute ,such as ~/.bashrc?

Wouldn't it be better if the app only had permission to write to an actual
user documents/data directory, rather than the home root? Which begs the next
question: _is_ there a standardized user document/data directory for desktop
linux that isn't just "~"?

~~~
zeroname
> Wouldn't it be better if the app only had permission to write to an actual
> user documents/data directory...

Well, would it? If the app went rogue, it could still encrypt all your
documents.

Either way, dealing with that is not the job of package management or software
installers. They can not solve the fundamental design issues of software that
has been written without a finer permissions model in mind.

------
brian_herman__
I dont see the point of This website if i am installing an application for
example gparted it can format my drives??

------
chb
They so don't deserve CoreOS. Pity they were able to acquire it.

------
JepZ
This is especially bad for projects like Linphone (open source SIP Client)
which exclusively provide Flatpak-builds for Linux [1].

[1]: [http://www.linphone.org/technical-
corner/linphone/downloads](http://www.linphone.org/technical-
corner/linphone/downloads)

~~~
confounded
I think flatpak is probably the right choice for a phone. Assuming equal
developer attention on both flatpak and deb repos, there's nothing inherently
worse about flatpak.

The nice thing about flatpak for a phone is that it _could_ in the future
offer something like the Android/iOS permissions interface.

~~~
JepZ
Yeah, maybe I am a bit too negative about the format itself. My problem with
the Flatpak only approach was that it was kinda hard to get it to run at all
and it didn't work particularly well, so I ended up with putting some work
into it while ending up with an unsolved problem (stable Linux desktop SIP
client).

So maybe this is not an inherent problem of this technology and will work
better in the future.

------
jiveturkey
oy. i'm not at all familiar with it but the author comes off as being on his
game so i'll take it at face value.

beyond disappointing that RH would release such a thing.

