[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

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

[2] 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.

[finchisko]

I like what Microsoft did in UWP. App is allowed to read own files, files explicitly selected by user from Open Dialog. For anything else app developer has to ask for permission and user has to approve it (like in iOS, Android....). Specially the second option is nice, because you as user have a choice to grant access only for specific files and dirs you want app to have the access.

[dpwm]

UWP sounds like it gets it right, but a lot depends on the granularity of the permissions. I'm not even sure you can win: too fine grained and the user ends up with permission fatigue and just clicks through, too coarse grained and the user has to choose between full access or no access. I think android gets this very wrong, but has improved somewhat.

I'm not sure if it's been tried but I think a better way might be to create some set of capabilities that can be applied, so you get complete confinement by default but can bulk set permissions of your choosing.

According to design docs, this is what is meant to happen with Flatpak. I'm not a user so I don't know how close it comes.

It appears that Flatpak falls short fo this with quite a few apps, which seems weird if they did implement the file portal they spoke of.

[gbraad]

Flatpak does not claim to be secure. This is also clearly stated in the FAQ. They provide a means of separation of applications. Sandboxing is not per se a form of security, just like this was with Docker in the 'early days'.

[syshum]

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

That is a weak argument to rebut the article. The author should not matter only the facts

Either what this person has claimed about Flatpak is true, or it is not

You do not need the persons name, address, and background to form that conclusion.

The only reason to demand that is to exert public pressure on them likely in an effort to silence them. Anonymous Speech is a cornerstone of a free society

[alxlaz]

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

Or by a person who does not wish to be on a no-hire list. The job market for Linux developers working on this sort of stuff is not exactly enormous.

[mfukar]

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

So glad that you can judge his points regardless of that irrelevant information, then.

[gbraad]

Nowhere on the page they claim to be secure. See also the https://flatpak.org/faq/. they are aware that security benefits at the moment are at a minimum.

Perhaps the term 'sandboxing'is being misunderstood as it was with docker. This is not per se a means of providing security.

[vanderZwan]

I'm going to stay a on the meta-discussions level for a bit (all other points in this debate have already been made anyway). Hanlon's Razor is about assuming intent, about railroading others into perceived roles. You bring up interesting points, but they were not part of the article we are responding to. The conclusion was supposed to follow from the earlier arguments given. Within that context there is a big assumption being made.

So what am I being naive about, exactly? Note that I have merely called out the assumptions made by others. I have not stated anything about Red Hat's intentions myself, so if I'm being perceived as naive about that, it would be making another assumption. EDIT: I suppose the "mistake" wording does imply good faith behavior. But there too: bad faith should be looked out for, tested for, but not presumed about others.

[TheDong]

> 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

They are using those features. flatpak has network namespaces for applications that don't need access to the network and bindmounts for applications that use very limited parts of the filesystem.

Sure, in reality many desktop apps have more far-reaching permissions, but all they're saying is that flatpak can make use of those features in some cases.

> This is flat out lying to try and get mindshare

Usually that's just called marketing. I don't think any of the above statements are actually lies in any way though. Can you point to what's actually a lie, or what lie is implied in your mind?

[jessaustin]

The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.

[derefr]

It's a sandbox like Android has a sandbox: each app lists a set of capabilities; the user gets a dialogue on installation where they have to grant those capabilities (or else cancel the install); and then for anything the app tries to do that's not in that set of capabilities, it fails.

A sandbox doesn't mean "you can never do [foo]." A sandbox means "you can never doo [foo] unless the user lets you." Even web browsers (the classical "true sandboxes") have an API that gets you access to the user's microphone, and another for access to their GPS data. There's just a dialogue in between that the user can say "No" to; and, having said no, the content of the tab can't ask again, and just gets denied automatically. That's what makes it a sandbox.

[jonstewart]

Is it also like Android's "sandbox" in that every application asks for every permission and the only choice is between "no security" and "can't install anything useful" and inures the user to just click "accept" on everything?

[Ndymium]

Android's permission system was overhauled in version 6 so that permissions are now generally asked when they are needed, for a specific type of operation, instead of the big dialog when installing.

I personally use several apps where I have granted one set of permissions and denied another (because it was for a feature I don't use). It has gotten a lot better than what it used to be.

[MayeulC]

For now, the GUIs are as far as I know, but there is a `flatpak override` command that seems promising for changing an installed application's permissions.

[viraptor]

The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided.

It's like standard Linux permissions. If you install an app which creates its directories with mode 0777, or install a package which has a suid binary, you don't complain that Linux offers no file access control. That's the author's or packager's fault.

[yzmtf2008]

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

[michaelmrose]

Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion.

In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed.

In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier.

It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions.

At best we are relying on the user to decide which app ought to get those permissions.

If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.

[comex]

Well, the ideal solution is to fix the application to use the special file chooser that gives the app permission to access whatever files the user chose. I only know the basics about Flatpak, but I know it has such a file chooser; does Gimp not use it, or is there some other issue that makes it require full home directory access?

In the meantime – sure, package the app, but it shouldn’t show up as “sandboxed” in the GUI if the sandbox isn’t meaningful. Instead it should come with a nice scary warning that the app has access to all of your files… you know, for everyone to ignore and click through. (You can lead a horse to water…)

[yellowapple]

In flatpak you are worse off, though, since - as the article indicates - they lag behind on security updates. If they get compromised by unpatched exploits, that sandbox is a valuable line of defense.

[viraptor]

It depends on your use case. If you sandbox tar (for example), you'd do it be removing all network access and a few fancy caps, but you'd leave the rw access to the whole system. (within its standard privileges) If you sandbox netcat, you'd do the opposite: remove all fs access (unless you care about pipes) and leave open networking.

There's nothing about the idea of a sandbox that requires a specific approach.

[voltagex_]

Have a look at AppV on Windows. It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.

[untog]

It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.

[yzmtf2008]

macOS does this via the open dialog — opening a directory gives an application full access to that directory

[pcwalton]

Same way it works on the web: Use a broker process that grants access via a file select dialog.

[voltagex_]

Virtualised paths with specific access - i.e. VS Code would only see one path.

[TheDong]

"sandbox" is an ill defined term, but what flatpak provides fits it perfectly well.

A sandbox is an environment where capabilities can be restricted in a set of ways.

The javascript sandbox lets you manipulate the website and make network requests, but not access arbitrary files.

The flatpak sandbox is configured per-app and can prevent all fs access, all file io (with seccomp), all networking, etc.

The article is simply pointing out that most popular applications do not use the sandbox features well.

That doesn't mean flatpak does not have the sandbox they claim to, merely that it does not mesh well with many popular apps currently.

I still see nothing that merits the word "lie".

[ricardobeat]

The sandbox is there for portability. I don't see a promise of being _more secure_ than other app distribution channels on linux anywhere. Though the packaging & sandboxing model certainly opens a path for improvements in the area.

Is it any less safe than installing something via aptitude or Ubuntu's app store?

[Shorel]

The alternative if using Ubuntu is called Snap. It has a sandbox and it is better implemented, at the very least the part about reading and writing in home dir.

[MayeulC]

As far as I was told, snap sandboxing only works with a specially-patched (and apparmor-enabled) kernel [1], though I am not sure what the current status is.

I would like to know what's better implemented in snap, it seems this is simply a case of most applications requesting a r/w permission in the home directory. It might get complicated sandboxing vs code without that, don't you think? Or at least lead to a subpar user experience.

I am hopeful it will improve, though. Sandboxing needs to become the default.

[1]: https://web.archive.org/web/20170615042616/https://github.co...

Edit: Similar echo here https://news.ycombinator.com/item?id=18180877