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

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.

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?!?

> 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.

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.

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

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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.

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…)

If an app doesn't get an security fix whoever maintains that package should be the one to blame.

Disclaimer: I don't like flatpak either, I'm just trying to be fair here...

Lo and Behold this is true.

The security gains even in the future are also probably mostly imaginary. You can't trust average users to understand the implications of granting permissions. By default if they are installing an app they trust the dev.

Further its not like malicious actors can't test against the sandbox and do the extra work to discover ways through the fence. Getting your target to run your malware tends to be game over outside of very heavily restricted environments.

If the browser had a build in fashion to ask the user to give them full control of the machine in a way that didn't look like malware 20% of users would end up with compromised devices.

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

Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM snapshots or a number of other things for a long time.

For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames. Still, you can do reasonably well by just granting access to any argument that looks like a filename. The Plash shell, a forerunner of modern sandbox designs, took this approach, but as an additional security measure only granted read access by default; if you wanted to run a command that writes to a file, you had to use special syntax before the filename [1]. Still reasonably usable, although there are other issues, like the fact that many Unix programs default to reading and/or writing to the current directory…

[1] http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-d...

That works where it works, but it seems like the sort of thing that will cause so much trouble that people end up turning it off. For example, a lot of files come with meta files containing thumbnails or other data with the same name but different extensions, or an associated directory with related data, and the app will want to access those too but a framework that doesn't understand they're related won't provide it.

You also end up with lots of little bugs, like breaking apps that predict what file you might open next and pre-load it or generate their own previews of files in the app's format.

A possible fix is that if the app tries to access a file you didn't expect it to, display an access prompt. But if that happens a lot it only conditions the user to just click yes every time.

> For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames.

You also don't know what's implied. Most commands default to operating on the current directory when not otherwise specified (e.g. as the output location for a tar extract), but half the time that's the root of the user's home directory.

There are many more applications, not just IDEs, where picking a file or folder is not sufficient: for example, apps like Rapid Photo Downloader or Darktable would be significantly crippled.

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".

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

In fact, it could be nicer if it catches on, as developers won't need to maintain deb files, rpm files, pacman files, etc.

I don't know whether it is true or not, but the author explicitly states that it is the official applications AND runtimes that aren't properly maintained.

> I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos

No you don't, because either (a) the package was not uploaded to the official (main) debian repository or (b) the debian security team is in charge of fixing it if the maintainer is no longer available.

Actually they do. Debian does carry local patches when necessary. It will also backport patches to release in older versions which may not be updated upstream. They literally make the updates happen.

In this case, it's valid to ask - where/when did you see the issue with this working.

That requires paid/volunteer package maintainers.

Sure, flatpak isn't making things worse by not being able to fix the fact that desktop users expect to open $HOME/screenshot.png in gimp, but it's also not going to easily fix that.

This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstraction.

Until then, this issue will be tricky to fix. I, of course, agree with your main point that things like updating packages more is fixable and the post is overly harsh and critical of what's effectively "things aren't perfect" with no empathy for how complicated stuff can be.

It does have that through portals:

https://github.com/flatpak/xdg-desktop-portal

If you Flatpak a Gtk+ 3 or modern Qt application you get portals for free. E.g. I packaged a Qt application and I am not sharing the home directory - when the user opens a file it uses the Qt/KDE portal (similarly to macOS, ChromeOS, etc.).

As far as I understand the problem is that portals are only available for Gtk+ and recent Qt versions. Some of the applications that the posts mentions use toolkits that probably don't support portals (Java JDK, wxWidgets, etc.).

The situation for Linux is a bit different than e.g. macOS, where practically everything uses Cocoa and Apple could just throw the switch.

So, for applications that do not use vanilla Gtk+ or Qt they still need to make the home directory visible or they would not be Flatpack'able.

But apps that don't do that because they're too old, just don't get access to the Store... or at least they didn't use to. Now you can ship non-sandboxed Win32 apps through the Store, and it doesn't even seem particularly obvious which ones are and which ones aren't. Windows 10 S only lets you install the sandboxed ones, but how many people use that?

So basically Windows couldn't solve that - the users ultimately decided that they care about stuff working as it did more than they did about security. I don't see why it would be any different on Linux.

There will always be legacy applications that will stay on old toolkits and they cannot fully benefit from sandboxing.

However, a lot of widely-used Linux applications that are on older toolkits are currently working on upgrades. E.g. Inkscape and The Gimp will be Gtk+3 applications. There are often other carrots, such as proper support for scaling for HiDPI screens, etc.

I have a fuse filesystem that shows different users different views of the filesystem, as a basic example.

The problem is rather caused by filesystem layout conventions. I think that a better solution would be to split user home directories into two classes of files: data (that is, files that the user typically wants to see and work with as part of the normal workflow) and "user profile" kind of stuff (.bashrc, configuration files, etc...) that should be "privileged" and require special access rights. These might require interactive confirmation before write access is granted (similar to the split user accounts in Windows with UAC). However, I wonder if these sets of files can be separated cleanly. Marking files as "privileged" should be doable using extended attributes, though.

If it was just about packaging, everyone would just have a build server that creates their binary once and then slams it through https://github.com/jordansissel/fpm.

But there are more fundamental differences between OSes than how the insides of their packages look. The packages are "differently shaped" to prevent you doing something stupid and damaging your OS by installing a package that will spew files in all the wrong places, and rely on classes of protections that aren't there.

Oh, also, a subset of case 2 is: packages that contain servers need to register the server as a service with the OS’s init system, and every OS has its own init system that expects a service definition file in its own distinct format and location.

Keep in mind that the separation you're talking about is very thin, often non-existent, in any OS. Consider, say, an RDBMS daemon. Is that an application, or part of the base system?

An application? You're sure? But what if components of the base system rely on its presence?

This isn't some wacky idea, and it's not a UNIXism, either. Some components of Windows Server rely on MSSQL. So MSSQL has to be built as a Windows component, rather than a standalone application.

This example helps a lot in understanding what OS packages really are. For example, why do Linux distros package scripting languages like Perl, Python, Ruby? It's not for you to use them to write system administration scripts. It's definitely not for applications to use as their runtime. (All the major distros recommend that you vendor your own runtime into your application, if you're creating a standalone application.) No, the point of these language-runtime packages is that there are system components written in these languages, and the OS package is there to support them.

And this is why you're supposed to install your own copy of these when using them for development: the OS copy isn't maintined for you. These OS-packaged runtimes are frequently not up-to-date, and they bundle with them some of the language's package ecosystem, but not all—and frequently not even the most popular language packages.

That's because the runtime isn't there for you. It's there for the OS to use. It may as well be hidden in /usr/libexec and not even in your $PATH. (Except that $PATH is frequently how system components find one-another.)

People make a mistake when they think it's a good idea to package their applications as e.g. Ubuntu PPAs following the Debian packaging guidelines. That format, and those guidelines, exist for the authoring of system components; the guidelines are the way they are (i.e. very strict) to enable other system components to rely on your component.

If you're building an application, none of that applies.

Until recently, applications on UNIX shipped as tarballs containing ./install.sh scripts that you'd have to run as root, that would unpack things into /opt but also maybe write some service scripts into /etc/init.d. (Even now, this is how heavily-integrated applications like VMWare ship.)

More recently, Docker has replaced this format when packaging applications that don't require much of the underlying platform (e.g. network servers.)

Flatpak and Snaps are two attempts to do for GUI apps what Docker did for network servers.

Unlike OS packages, Docker, Flatpak, and Snaps are all interchangable and inter-convertable as long as you have an application that only requires their least-common-denominator subset of capabilities. A Docker "package" can be repackaged as a Flatpak or Snap losslessly. There is no reason that the Flatpak and Snap ecosystems can't proxy through to Docker Hub and let you pull any Docker image and run it under their daemon. There's no real war here.

The reason configuration sucks is because we use filesystems, which are necessarily hierarchical, when we should use a more general database.

If we had a table where the first column was "thing to be configured" and the second column was "program" things would be much better. We could query by the first column to get e.g. all programs that want to automatically start, or all programs in path. Or we could query the second column to get all configuration for a given program.

Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that.

It's kind of amusing that on the Windows side, you have a vertical integration between the filesystem (NTFS) and the update mechanism, where any MSI package will actually be installed in a filesystem transaction, such that if you e.g. cut power in the middle of package installation, then your disk will actually have nothing of the package's installed data on it. The transaction failed, and was rolled back.

And yet, even with that fancy tech in place, uninstallers still are manually-written apps that blow away files by explicitly naming them, rather than also taking advantage of these filesystem-level transactions together with some sort of hypothetical transaction WAL log, to reverse what the install did.

https://docs.microsoft.com/en-us/windows/desktop/fileio/depr...

Most distributions need non-free explicitly enabled, so almost all packages are open source, so it is irrelevant to distro packaging format.

Yep - all of those. GIMP has scripting capabilities and exposure to vulnerabilities via image codecs, same as Inkscape, and Audacity could be linked to ffmpeg, which is a huge attack surface.

Fucking none of it, that's your answer.

---

The list on the page is

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

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

1. the File Open dialog is itself the permission prompt.

2. documents consisting of many files are structured into project bundles; you open—and thus grant access to—the entire bundle at once.

3. the GUI is structured to orient activity around documents rather than around applications. You hardly ever launch an app and then open a file in it. Instead, you open the document and the app is its default handler; or you right click the file and Open With the app; or you drop the file onto the app's launcher shortcut; or you drop the file onto the running app window. All of these actions implicitly grant the app permission to open the file, in the same way the File Open dialog does.

4. Apps can persist the token representing this granted permission in a serialized state file, and it will even survive OS reboots. There are some macOS utilities (e.g. DaisyDisk) that need access to your entire disk—but you only need to grant this access once. (DaisyDisk asks, on first startup, for you to open the Finder and drop the icon representing your primary hard disk onto the running app.)

And yet, there are quite some applications that ask you to open the home directory once so that it gets symlinked into their sandbox. It's basically a hack to say 'I need access to your whole home directory'. Of course, it is safer than permitting access by default.

Of course, in many cases there are good reasons (backup software, space usage analyzers). But not everything can be mediated through file dialogs.

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

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).

I don't think AppArmor has such a facility. It wouldn't make sense, given that AppArmor doesn't know these things like SELinux would.

If an image manipulation software wants to open .bashrc, allow it. If it has permission to write to one, so be it. If .bashrc is such a security nightmare, then perhaps the issue is that programs can write to it. Remove the write permission. Perhaps a security model where restoring permission asks for password.

That would seem to be the obvious right choice. What's the problem with it?

Gimp would only get access to image/* (not sure it needs something else? Adapt in the case it does). Of course, this requires adjusting the current development workflow (maintain a list of filetypes needed, for example).

If you want to push this further, you could imagine a permission system that can distuingish based on file types. Gimp overwriting a PNG is probably intended, Gimp overwriting a bash script probably not.

There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".

It's more nuanced than that. A user might not even have a .bashrc, but you still don't want to allow any random app to create one.

In general, it feels like the security model for the FS has to distinguish things that can be executed, and things that cannot. Which it already does on Unix with +x, but then you've got all the scripting languages that cheerfully ignore that, and all the apps that use executable configs etc. If you can fix all those such that +x is required for any source of executable code on the system, then you can just prohibit apps from creating +x files. But the cost of doing that in the existing ecosystem is enormous.

In fact I'm struggling to think of a single file type that truly won't have a use in emacs.

(It might actually make more sense to forbid editting executable files than going via type)

-----

>There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".

The problem isn't that there isn't a lot of "nuance" in these systems, the problem is that there is!

Sure, SELinux will work if you have a static system or an SELinux expert under the desk.

Creating a system that works and remains understandable is much harder.

With the current situation, calling the programs sandboxed is completely misleading.

It also has the benefit of using the KDE file-chooser on KDE, Windows file-chooser on Windows, mac, etc...

That is not very good.

Suppose you create an audio file with Audacity and a series of images with ImageMagick and GIMP, then use ffmpeg to combine them into a video and VLC to view it. They're all operating on the same files.

What we need is to add an application list to filesystem ACLs and then have security groups like Video and Finances which contain apps. Because GIMP should be able to access your photos but not your accounting spreadsheet.

It should even be possible to do some of this automatically by file type, e.g. GIMP can access any PNG file the user can but not any spreadsheet file, or read a shared library but not write to it.

Does anything remotely resembling this already exist?

Edit: Before anyone says that SELinux resembles this, as far as I'm aware SELinux policies are anything but simple to set up and use correctly. However, SELinux types are inherited from parent directories and do look an awful lot like this. The main thing missing would seem to be that I can't find how to apply multiple contexts or types to a single file, but perhaps I'm just failing to navigate the manual?

This isn't that hard in a technical sense. But I very much doubt you can get the casual users to actually do that. They'll just end up with one giant group, because it's the easiest and doesn't require understanding the concept of security boundaries.

Basically, it'd be Vista UAC prompts all over again.

It is more cumbersome to use than the current mainstream paradigm, but not that much!

[1] https://www.qubes-os.org/intro/

Of course, it is silly to sandbox your bread-winning software. I don't sandbox Android Studio. Or ffmpeg. Or VLC. Personally, I believe that nobody has a right to decide, how to sandbox software on other people's computers. I think, that such decision should be left to users of that software. Unfortunately, it looks like Flatpak does not make that easy.

I stopped using desktop Linux a long time ago and now use a Mac for my desktop work. I take things a bit further and don't let anything write to my $HOME/Desktop -- it's read-only. I don't recommend that as a default for anyone either!

But as far as Flatpak, a few of the "featured" apps are things like Inkscape, Gimp, VLC, or LibreOffice. Not apps that you'd really want to sandbox isolate like you described. (And as you mentioned -- you wouldn't want to do that anyway).

Now a few of the others were Spotify and Slack. Things that you could (should?) definitely sandbox.

I guess I don't see the point in having applications (that is intended for a general purpose user) that (a) need access to your home directory to read/write files and (b) should only have access to a sandboxed pseudo-home directory. Either sandbox it so it doesn't have $HOME access at all, or don't. I'm not sure I see the benefit to this middle ground. Especially for the use-case of general user desktop applications. For server applications, I could potentially see the benefit (although, containers have probably already filled this scenario). What is the use-case you're thinking of?

I appreciate your point of view that no one should be able to decided for you how to sandbox software, but no one is forcing you to use Flatpak packaged programs[1]. Perhaps there should be some way to re-build a Manifest that limits access, or make it so that you can more easily switch granted privileges -- that would probably be a good thing. But someone has to set defaults. If a Flatpak packaged program has too liberal defaults, then maybe that's best treated like a bug and hopefully there is a mechanism to send a patch.

[1] yet... but it might be coming. I think the only way you'd see commercial applications like Photoshop for desktop Linux would be wrapped in something like Flatpak. I still think that most open-source applications will still be packaged by the main distro repositories, regardless of how well Flatpak does.

I'm curious how you do this? What's your setup?

I don't use Flatpak etc. — all of my jails use system-wide libraries and executables. They are just launched inside sandbox environment.

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.

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.

That's true in principle, but selinux still doesn't see that much adoption outside of the distro configured policies for typical server usecases. A lot of desktop apps run unconfined. So I think this is where openbsd's approach to stuff like this is more practical. They iterate and wait before rolling out features like pledge or unveil so that they know that 1) It can be made to work with at least 50 apps (read this is one of their slide decks) 2) They can tackle a complex enough application like chromium. Flatpak, selinux or any of the other security mechanisms are completely ineffective if users or developers are largely ignoring them.

SELinux works by default on Fedora, and even has a nice GUI popup that explains to you what happened when an SELinux policy blocked an action (so that you can reconfigure it). It's pretty neat, and is massive improvement to SELinux of old -- I would recommend trying it if you haven't recently.

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

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.

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!

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.

    wbond@u1804:/var/lib/flatpak/app/com.sublimetext.three$ find . -iname 'git' 
    wbond@u1804:/var/lib/flatpak/app/com.sublimetext.three$

https://flathub.org/apps/details/com.sublimetext.three

I do not use Sublime Text personally, but if I ever want to try it, I'd do it trough a flatpak. Yes, sandboxing permissions might not be perfect yet, but a little sandboxing is always better than none...

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

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.)

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. 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 :).

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

I'm assuming with "LSM stacking" that you mean having both AppArmor and SELinux operate concurrently on a system, since you can currently have kernels that have both enabled, but only one at a time active.

Are you going to convince Red Hat to enable AppArmor and support stacking SELinux and AppArmor in RHEL? What about helping to maintain AppArmor support in Fedora? Without that piece, that's not a valid or useful solution because you're hoping for something that won't help any of those people (like me!) at all.

I'm pretty sure that everyone will say no to the idea of combining AppArmor with SELinux, since it's basically insane and requires developing and maintaining policies for both that don't conflict with each other. Having written these things for my apps, I wouldn't wish the combination of both on a single system on my worst enemy. That's a lot of security check policies to work through!

> 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.

Sure, but if people do keep asking for full support, that implies having SELinux support to enable full confinement. As I said above, unless you intend to actually do the work and convince Red Hat to make the necessary functionality available, you're going to need to support SELinux as a proper backend.

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

I think you missed the point. But sure, maybe. If there wasn't the CLA to get in the way... Why do you have that when you already offer it under a nice copyleft license?

The term "LSM stacking" is public. Search for it and you'll get good material.

> Are you going to convince Red Hat to

That's not how things work. Canonical and RedHat collaborate technically by improving parts of the system as necessary. Things are enabled or not based on market requirements.

> What about helping to maintain AppArmor support in Fedora?

Canonical already does that by working to upstream the patches. That helps Fedora and everybody else too.

> I'm pretty sure that everyone will say no to the idea of combining AppArmor with SELinux

Well, no need to guess.. there are open discussions about it.

> I think you missed the point. But sure, maybe. If there wasn't the CLA to get in the way...

For legal reasons that are not unique to Canonical we do require a pretty straightforward CLA to be signed. I've signed that sort of CLA myself for other large companies, both individually and in the name of Canonical, so the playing field is level here.

Umm, but your ability to offer useful confinement literally hinges on this since you don't want to do anything else...

So, you'd have to do something to get Red Hat to consider enabling it. Otherwise you're stuck with nothing for Snappy on the most commonly used Linux distribution platform in the commercial space.

>> What about helping to maintain AppArmor support in Fedora? > Canonical already does that by working to upstream the patches. That helps Fedora and everybody else too.

It doesn't help Fedora at all today, since there is no AppArmor support in the distribution. The user-space tools aren't in there, and the kernels shipped by Fedora do not have AppArmor enabled. So, no, I can categorically say you are wrong there.

> Well, no need to guess.. there are open discussions about it.

Really? Because I searched, and outside of John Johansen's wishful thinking presentations, I've seen no evidence of anyone talking about it seriously. If anything, I've heard people say John is crazy for thinking that this is a reasonable idea.

Care to offer some proof to the contrary? Who knows, you might be right! It seems that the LSM mailing list has no functioning archive, so there could be something there that says otherwise.

> For legal reasons that are not unique to Canonical we do require a pretty straightforward CLA to be signed.

No other major Linux company requires one. Not Red Hat. Not SUSE.

Snappy packager for Fedora here! :)

Yes, it's true there's an SELinux policy that confines snapd, but it does do some limited enforcement of limitations on snaps, too. It's just not as nice as I'd like, but that requires snapd to learn how to work SELinux, which I can't really do...

And yeah, I tested the policy on Debian too, it works! It should work on openSUSE too, though it might need a slight tweak.

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

I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do.

No, that's also incorrect if you slice it by popularity. We don't have a public chart easily filtered by these aspects together, but just pick some random samples.

It's also easy to see that based on the low volume of classic snap requests in the forum, vs. the volume of actual snaps published and announced in the open.

Docs: https://docs.snapcraft.io/build-snaps/electron

Example: snap info electron-quick-start

Sounds fast to me if you know how. Just write the article (markdown + pandoc is fast) and...

With Zeit you can just type `now` and `now alias (url) mydomain.xyz` - and the website is up and running at your domain for $domain_price + 0.10USD/GB.

With DigitalOcean/Vultr/Some VPS Provider + Ansible you can do something similar.

I am among the laziest people I know and even I'm raising an eyebrow at this statement.

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

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

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

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

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.

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.

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.

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

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.

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.

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.

The (long) goal of flatpak is that the user would never download and execute from the browser, everything is updated through the flatpak repos (like the PPAs for .deb) but with the addition that the apps are sandboxed and follow a runtime model for dependency instead of packaging everything or depending on other packages.

Basically the goal is to have something like on Android or IOS , so exactly the opposite of the "download from the browser and run an untrusted executable"

Just to be clear; the "download" model I was describing is not "download and execute the actual app from the browser", it is "download and execute an installer from the browser". Then either clicking on the installer or dragging it somewhere (on Macs it used to be dragging to the desktop, but I haven't used Macs for several OS X versions now) starts the installer.

> everything is updated through the flatpak repos (like the PPAs for .deb)

This I would have no problem with; I would be able judge whether I trust their PPA the same way I judge any other third party PPA (or the distro itself, for that matter). And the update would be through the normal mechanism I use to update everything on my system, which has well-tested security measures built into it.

> but with the addition that the apps are sandboxed and follow a runtime model for dependency instead of packaging everything or depending on other packages.

I understand the benefits of this as far as fixing dependency hell. But it doesn't seem like the sandboxing part works as advertised.

> Basically the goal is to have something like on Android or IOS

I'm not sure this is a good way to phrase the comparison since it implies not just sandboxing/packaging, but an app store curated by a large corporation whose interests don't align with mine, various broken permissions models, etc.

In other words, Linux is secure because nobody can ship software on it without going through massive hurdles and because everybody who is smart enough to install software on Linux does some diligence.

You can totally download binaries from the internet and execute them if they don't require libraries (if the binary even needs any libraries, ie not statically compiled).

You can also download a .sh installer and execute that to install software, it can even create an icon on your desktop (if you even still have one of those that has icons ;) ). Unfortunately, there's a ton of software that installs like this on Linux.

Edit: Grammar

I, as a developer, am not sure I care. It's tough for me to care about Linux in the first place (you guys are picky!), but let's say I went through the trouble of maintaining multiple third-party repositories for major distributions, how exactly is that more secure from your perspective? You still have to trust that I don't ship malicious binaries, just as if you just had downloaded the package from my website. Worse yet, you also trust that I maintain all these repositories securely, which means a bigger attack surface for you.

> The extra work involved in setting up secure distribution is a feature, not a bug.

Except it isn't really secure from a technical perspective, it's literally just more work.

I'm not saying you have to care. If your software is so good that I need to have it, then either my distro will have it, or you'll have set up some kind of distribution infrastructure that I can use securely, or, if I have to, I'll download your source code and build it myself. OTOH, if I don't need your software, and it's not easily available to me securely through my distro, then I just won't use it.

> It's tough for me to care about Linux in the first place (you guys are picky!),

Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them.

> let's say I went through the trouble of maintaining multiple third-party repositories for major distributions, how exactly is that more secure from your perspective? You still have to trust that I don't ship malicious binaries, just as if you just had downloaded the package from my website.

If I'm getting binaries from you directly (instead of from my distro's maintainers, who are building binaries from your open source code), then yes, I have to trust them. If downloading them from your website is the only way you'll give them to me, and your software is so good that I need to have it, then I'll end up downloading them from your website. So far, the set of software that is so good I'm willing to do that, and which forces me to do that by giving me no other alternative, is empty.

Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA. The software that is so good that I'd be willing to download it from your website without all those precautions is not only empty, it is inconceivable to me that it will ever be anything other than empty (whereas I can at least conceive it being possible that somebody, sometime, will write software that's so good that I'll go to their website to download, with all of those precautions, if given no other option).

And also again, if you don't supply a third-party PPA that my distro's package manager can pull updates from automatically, how are you going to ship me updates? Are you going to ask me to go to your website every time? Or are you going to reinvent, poorly, the packaging and updating infrastructure that has already been field tested for years by distros?

This is how most professional Windows desktop software is distributed today. Also, you don't need a signed hash if the binaries are code-signed - you can verify that they haven't been tampered with by simply right-clicking on the binary and looking at the cert/SHA-1/SHA-2 signatures.

So far, that seems like a very reasonable compromise for both of us.

> Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them.

I don't see your point. If it's about Microsoft's data collection, that's orthogonal to how software distribution works. Otherwise, there's no reason to trust the competence of Canonical or RedHat employees (or even volunteers for other distros) over those of Apple or Microsoft. Either one can mess up, either one can expose your system.

> Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA.

It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to provide dozens of packages built against the dependencies of whichever versions of those distributions are currently in use. That's the actual problem Flatpak is solving. If there was one package format that worked everywhere, it would be a different story. You can trivially download and install (compatible) deb or rpm files as well, why aren't you lamenting that being a security issue?

> And also again, if you don't supply a third-party PPA that my distro's package manager can pull updates from automatically, how are you going to ship me updates?

Your distribution could integrate Flatpak updates into its update mechanism, or you can run them manually or as a cron job.

> Or are you going to reinvent, poorly, the packaging and updating infrastructure that has already been field tested for years by distros?

Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably. On the other hand, the software that has all its dependencies in one place, where an update consists of overwriting or replacing the installation directory, has rarely failed. On Windows, this is called "portable", on Mac OS, this is simply a regular application.

What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner.

> It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to provide dozens of packages built against the dependencies of whichever versions of those distributions are currently in use.

Get your package into Debian and Fedora, other distros might pick it up. If your software is popular enough, someone might volunteer to do the packaging for you. If it's something I care about and not available, I'll compile it (if it's a compiled language). If it's something I care about and it needs to go into production, I'd build and maintain my own rpms or debs internally.

Fedora and especially Arch are big offenders. Debian is so "stable" that I can't install newer software through the provided packages anyway, so that's trading off one failure over another.

> Get your package into Debian and Fedora...

If you stay inside the FOSS bubble, of course maybe some maintainer will eventually spend their precious time packaging some version of your application in some (sometimes broken) fashion. I don't think that's a good solution even for FOSS, but for non-FOSS it's not even on the table.

I've already addressed this, it's pretty trivial to recompile most major software packages. You can also pull those packages from testing or unstable.

> but for non-FOSS it's not even on the table.

Sucks to be a proprietary software vendor. You have to do all this hard work for people to not buy your product anyway.

Is it not obvious that outside of the Linux bubble people are not looking forward to invest their precious time into such things?

> Sucks to be a proprietary software vendor. You have to do all this hard work for people to not buy your product anyway.

Of course the alternative is to just ignore Linux users like most proprietary software vendors do.

(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 ?

I'd greatly prefer 'native' packages though.

The flaw this post seems to highlight is that they shouldn't claim that they are sandboxed when they aren't. But even without sandboxing they're still a good thing.

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.

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.

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?

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).

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

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.

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.

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.

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.

For example if this site is by the Snap developers...

* https://devuan.org/os/team/

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.

Docker has support for user namespaces but it's off by default, and I've never actually seen someone use them (I'm sure people do, but the way the support was implemented is fairly half-baked in a variety of ways, for a variety of understandable but still disappointing reasons).

LXC/LXD's user namespace implementation actually privilege-separates different containers from each other (while also being able to "punch out" parts of the mapping so that you can share stuff between containers without needing to share the entire uid_map).

> user namespaces requiring privileges to use

Not always. See https://github.com/rootlesscontainers (a project I work on -- currently you can run Kubernetes as an unprivileged user with some caveats about multi-node setups but we're working on it) or LXC's unprivileged containers.

And in cases where you need to have multi-user mappings (which isn't necessary for most user applications because they wouldn't be able to setuid anyway!) you can just use "newuidmap" and "newgidmap".

In fact, bubblewrap has supported precisely this usecase and the use of user namespaces for a while. Of course, user namespaces wouldn't really help with protecting against home directory attacks -- if you're running as the same user (but in a user namespace) and you bind-mount the home directory then it can obviously write to said home directory.

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

[1]: https://news.ycombinator.com/item?id=18181034

binctr looks like an interesting solution to tackle this issue.

[1] https://blog.jessfraz.com/post/getting-towards-real-sandbox-...

[2] https://github.com/genuinetools/binctr

[3] https://news.ycombinator.com/item?id=18180276

I worked quite a bit on getting this userspace stuff together (though of course the kernel work was done by much more clever people than myself :P).

[1]: https://github.com/rootlesscontainers [2]: https://github.com/openSUSE/umoci

Which is to say, when you hand out the privileges laid out in the article, it really doesn't matter what software you used to whitelist "every thing".

I'm thinking of all the blogs back a few years ago for setting up things on Centos. Step 1, disable SELinux.. That was never recommended, but the blog writers didn't want to go into details about how to manage selinux, or couldn't understand it.

With that said, some people might consider a system that is much easier to trivially work around than to use properly is one possessed of a wonderful, glorious, bountiful collection of opportunities to improve its design. Such systems are not bad! Not by any means! They just could, perhaps, be somewhat better.

All of that said, I do think a sandbox-based system probably shouldn't allow things inside the sandbox to say "Don't sandbox me bro". That seems less than maximally wise, even if it does also seem super convenient.

As far as I have seen, privileged container use is rare. What lead you to the assumption that it isn't?

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

Gtk added GtkFileChooserNative for just this purpose. It implements the same file-chooser interface as other dialogs so in many cases is a couple line change to apps. Sadly, it can't be done automatically because various API/ABI reasons.