16 ms·

Flatpak – a security nightmare

377 points by stryk 8y ago

pdonis 8y ago
I share this writer's concerns with Flatpak. It looks to me like yet another attempt to bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux.
- zeroname 8y ago
  This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. 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.
  - pdonis 8y ago
    > This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. True, it isn't any less broken than that; it's more broken. First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). That's by design: it should take some work on the user's part to download and install software that hasn't been vetted by their distro. Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.) Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure". Promising that your apps are sandboxed means they need to actually be sandboxed; disabling the sandbox with default privilege settings breaks that promise. So users get less security than they think they are getting with this model. > Linux is secure because nobody can ship software on it without going through massive hurdles Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.) > everybody who is smart enough to install software on Linux does some diligence. Nothing can protect a user who is not smart enough to do some due diligence before installing software. So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security.
    - zeroname 8y ago
      > First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user... There are no "average" Linux users. There's only Linux nerds and people who have had their Linux nerd friends install and maintain Linux for them. The whole "problem" is made up. > Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.) 2525 Year of the Linux Desktop > Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure". I haven't seen Flatpak touted to have a security sandbox, nowhere on their site do I see "security" being even mentioned as a feature. So that accusation is made up as far as I am concerned. > Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.) Gee, a thousand FOSS applications, what more could a user want? Have you personally ever tried to ship software for "Linux"? Do you even develop software? > So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security. It's "security by inconvenience". This has nothing to do with real security. These users you are trying to protect don't exist, but even if they did, you wouldn't protect them by making it hard for them to install software, you would be making them use Windows instead.
    - linuxftw 8y ago
      > is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). 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
      - pdonis 8y ago
- stephenr 8y ago
  > bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux. Wat? Windows famously doesn’t have “just drag it to your desktop” to install. There’s an entire segment of the industry around building installers and managers for installation of windows programs. And I can’t recall a single mac-affecting malware that spread the way you describe except maliciously modified versions of pirated commercial software (eg adobe stuff) which doesn’t actually install via drag and drop anyway - it has an “installer” if its own.
  - ambrice 8y ago
    I think the reference is to the fact that on Windows you download some random .exe installer from some place on the internet and trust it, rather than selecting a signed package from a trusted repository that gets automatically updated. Should have been "download it, drag it to your desktop, and install it".
    - pdonis 8y ago
      Yes, this is what I was referring to. Sorry for my unclear phrasing.
- Natela 8y ago
  What ? No it's exactly the opposite ! I think you're confusing with AppImage maybe which is indeed download from the browser & run. 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"
  - pdonis 8y ago
    > The (long) goal of flatpak is that the user would never download and execute from the browser 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.
jiveturkey 8y ago
oy. i'm not at all familiar with it but the author comes off as being on his game so i'll take it at face value. beyond disappointing that RH would release such a thing.
glglwty 8y ago
Is the sandboxing of flatpak more or less secure than docker?
- Kalium 8y ago
  As I understand it, from reading this page it doesn't actually matter much how secure the sandbox is as many applications effectively disable it.
  - briffle 8y ago
    And many docker users run privileged containers, because then they don't need to troubleshoot permissions.. It doesn't meant the underlying system is flawed, because people take the lazy way around it. 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.
    - Kalium 8y ago
      You're right! It's not the fault of the underlying system, it's the fault of the lazy people who work around it trivially. 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.
    - the_duke 8y ago
      I almost never had to run a privileged container, and I avoid it whenever possible. As far as I have seen, privileged container use is rare. What lead you to the assumption that it isn't?
      - 8y ago
Ecco 8y ago
Wait a minute, did somebody get so pissed at flatpak that they bought a domain name just to specifically host that single blog post?
- TeMPOraL 8y ago
  Domains are cheap. Often free for one year.
  - Ecco 8y ago
    Well they’re “free” if you buy them alongside hosting. Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc...
    - TeMPOraL 8y ago
      > Well they’re “free” if you buy them alongside hosting. Depends on hosting company. I've "bought" domains for free many times, without hosting, just to run joke sites for few months.
      - Ecco 8y ago
        Ha, interesting! I always assumed a .org was at least a dollar. Mind sharing a link?
        TeMPOraL 8y ago
        Don't have a free "org" source; maybe they never was. Free domains I got were under national TLD.
    - ReverseCold 8y ago
      > that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it 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.
vanderZwan 8y ago
> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security. Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion like this is not going to make it more likely that they admit their mistakes. A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly. [0] https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor
- briffle 8y ago
  Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. 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. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by the developers to maintain it) In fact, it could be nicer if it catches on, as developers won't need to maintain deb files, rpm files, pacman files, etc.
  - kilburn 8y ago
    > his other major gripe is that the security updates for non-official flatpaks 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.
    - geofft 8y ago
      The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. The Debian security team is a volunteer team, and it's entirely realistic that someone may actually have seen delays in the packages they care about getting security updates. "No you don't" is arrogant - you have no way of knowing that.
phaer 8y ago
Could someone knowledgeable enough comment on how this compares to Cannoicals Snappy https://en.wikipedia.org/wiki/Snappy_(package_manager) https://en.wikipedia.org/wiki/Snappy_(package_manager)?
- jayrwren 8y ago
  It's exactly the same state.
  - niemeyer 8y ago
    No, not really. Files at ~/.* were never readable or writable for strict snaps, even when they were granted the "home" interface, precisely for that sort of reason. The file permissions and ownership are also strictly checked by the store (no setuid bit issue). Classic snaps depend on manual approval, and need to be acknowledged by the user before being installed for that reason, etc.
- linappdev 8y ago
  With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers. So, for example, on Fedora, Debian, CentOS, or openSUSE, snaps run in "devmode" because of the missing functionality. There's been some work over the last couple of years to upstream some of the work on AppArmor (so openSUSE may partially work in the future). There's a desire to support SELinux properly, but to date, no work has been done. There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too). Based on conversations I've had with the Snappy team before, it comes down to two things: * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to * Canonical's customers haven't demanded it of them yet I find the latter point especially strange given the constant demand for official Snappy support on CentOS and Amazon Linux 2 (which is currently not available yet). Both distributions have SELinux and rely on it for security. In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement. That is, they're not confined, and have full access to the system, they just use snapd as the delivery system for the software. So even if Snappy confinement actually worked on all Linux distributions, it doesn't matter because most apps delivered through Snappy are entirely unconfined. Finally, Canonical is the sole arbiter of snaps. You cannot use your own store with it, as snapd is hardwired to Canonical's store. They own all the namespaces, and are the sole publisher. And yet, they have a confusing policy of how they don't consider themselves the distributor of software when they are... It's strange. But because you can't run your own store, you're at their mercy for snap names, available functionality, and so on. Flatpak, in contrast, is designed to offer the fullest confinement possible with common security features in the mainline Linux kernel that all major distributions offer. Applications register what they need in their manifests, and the Flatpak system handles granting access as appropriate. Flatpak relies on federation through "portals" for interacting with the host environment, and that allows for the applications to have far less direct access than they would normally have. It's basically an Android-like setup, and it seems to work well, though it's still far too coarse for some kinds of applications. Flatpak lets you run your own repository, so you can implement whatever means you'd like for delivering them, even keyed paywall locations, so that customers who pay get their own access to their own purchases. But most apps probably should be pushed to Flathub, especially if they're free. I think no one has figured out yet how to do paid stuff. (Disclaimer: I'm a Linux app developer that grudgingly deals with both formats. I'd rather just keep using RPMs myself, as it works well and is reasonably portable.)
dralley 8y ago
Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action causes a prompt. Now, that's not to say this is good as it is, but for most listed programs it's probably the way to go.
- blattimwind 8y ago
  File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.
  - aaaaaaaaaab 8y ago
    That’s how macOS sandboxing works too.
  - TeMPOraL 8y ago
    Do you open your files in PyCharm or VSCode through a file picker?
    - blattimwind 8y ago
      Drag and drop project folder. Also, yes, I do open project directories using PyCharm's (poor) file picker.
    - stephenr 8y ago
      I’d imagine once you open a directory you can open files within it (and child dirs)
    - ReverseCold 8y ago
      You open the parent project directory, right? That's how the file access controls work in MacOS. Sandboxed apps can't read files outside their sandbox until the user opens the directory/file in the file picker at least once. (Or something similar, I can't seem to find a source on that...)
jopsen 8y ago
flatpak is still early.. most apps are still installed from package managers, and few apps are written with flatpak in mind. The current situation is probably not much worse than installing from various third party package archives. I suspect things will get better as adopting catches on.. it's no surprise that early stage open source software have rough edges.
JepZ 8y ago
This is especially bad for projects like Linphone (open source SIP Client) which exclusively provide Flatpak-builds for Linux [1]. [1]: http://www.linphone.org/technical-corner/linphone/downloads http://www.linphone.org/technical-corner/linphone/downloads
- confounded 8y ago
  I think flatpak is probably the right choice for a phone. Assuming equal developer attention on both flatpak and deb repos, there's nothing inherently worse about flatpak. The nice thing about flatpak for a phone is that it could in the future offer something like the Android/iOS permissions interface.
  - JepZ 8y ago
    Yeah, maybe I am a bit too negative about the format itself. My problem with the Flatpak only approach was that it was kinda hard to get it to run at all and it didn't work particularly well, so I ended up with putting some work into it while ending up with an unsolved problem (stable Linux desktop SIP client). So maybe this is not an inherent problem of this technology and will work better in the future.
Pica_soO 8y ago
So a secure implementation will be written, breaking everyone's code and workflow. The resulting rage of the users will then be used to silence the security concerned, and a great checkbox will be painted under the door-mat [Informed consent is given by foot stomp] and the world rotates on.
jbk 8y ago
> VLC [...] filesystem=host See my comment on why it's not easy to fully sandbox software like VLC: https://news.ycombinator.com/item?id=14409234 https://news.ycombinator.com/item?id=14409234 The author is correct, in the fact that flatpak-vlc is not a secure sandbox.
- laurent123456 8y ago
  Thanks for sharing the info. I'm just curious - how would splitting VLC into multi processes solve the permission issue, since the sub-processes will still need access anyway?
  - jbk 8y ago
    Each subprocess would only get one permission, the one that it actually need. The critical parts (audio decoders, video decoders, parsers) would not get access to $HOME or network, for example.
    - laurent123456 8y ago
      Thanks, that makes sense.
zeroname 8y ago
"Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it." No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects flatpak and literally every other form of installing those same programs outside of a sandbox.
- audidude 8y ago
  If we could get applications to switch to using APIs backed by the xdg-desktop-portal, then they don't even get access to the host/home filesystems. They talk to a service which sends a FUSE FD to the app, and that overwrites the original file when close()d (but never does the app get direct filesystem access). 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.
- iforgotpassword 8y ago
  Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not. A flatpack sharing any part of the host file system with the app should be marked as insecure when installing and/or launching.
  - zeroname 8y ago
    > Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not. It is isn't being sold as "secure". It's sandboxed in the same way that Python virtual environment is sandboxed, i.e. you're not messing with the system software installation. Real security sandboxing is a completely orthogonal feature that package managers do not deliver either.
    - irishsultan 8y ago
      Honestly, that's not what I would expect sandboxed to mean. By that definition installation in /opt/$vendor/$software/$version would also be sand-boxed.
ktpsns 8y ago
To be honest, this security nightmare also covers other contemporary "container" formats such as docker. Running docker containers as a non-root user is unfortunately still not a widespread practice. That means that any root process within a docker container has root on the host.
- viraptor 8y ago
  Only if you run with no isolation / user namespace. And even without that, you need to run with `--privileged` to get access to interesting capabilities. It's not as simple as container root == host root.
  - yrro 8y ago
    Are user namespaces enabled by default, or are they something that you have to enable and then spend time dealing with all the containers that weren't written with them in mind?
anon_cow1111 8y ago
Random mint 18.04 user here. I just noticed about a week ago that flatpak was downloading huge amounts of data (like hundreds of MBs). I had all system updates set to download and install manually, and hadn't installed anything new for at least a month. All this data was getting sent to /var/tmp as flatpak-cache folders. I don't know what it was doing but I've since turned it off in the startup list. Any ideas? What are the chances this was malicious?
- c487bd62 8y ago
  I'm not a flatpaker but maybe it was updating the runtimes? http://docs.flatpak.org/en/latest/available-runtimes.html http://docs.flatpak.org/en/latest/available-runtimes.html Honestly I would be more worried about running mint (a topic not suited for this thread, a quick search would probably show you what I've read about it in the past).
nickysielicki 8y ago
1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged. 2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub. 3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a package to make sure that permissions are perfect. There is no reason that these issues can't be ironed out going forward.
- aritmo 8y ago
  But Flathub is flatpak. Also, does flatpak have the full support of redhat?
  - Natela 8y ago
    No. Flathub has nothing to do with flatpak technology itself. Flathub is just one server hosting some flatpack repos. It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many other you could add to get your apps
    - int_19h 8y ago
      Isn't the whole point of Flatpak to prevent the same app from being packaged multiple times for different distros?
      - Natela 8y ago
        Ideally , Firefox would be downloaded from official Mozilla Flatpak repo, Blender from Blender Flatpak repo on Blender server, etc... And we would have this list of those repo on our distro. However because the official adoption is slow (very few software have official flatpak repo), flathub allowed the community to build packages themselves. But this is clearly not how it should be. The second (more legit) reason of flathub is that small developer might not want to pay a server to host their app and flathub proposes to host their repo.
  - 8y ago
Natela 8y ago
The sandbox is in a sense working, the problem is that the folder the app accesses is more critical than what the user thought. We should make sure nothing in home will get executed : no bashrc, no scripts, no executable. In the "ideal" world you would never download & run any script or any executable (like on Android or IOS). Everything the user should be able to do is install or run flatpak apps. (Of course in practice as soon as you are programming a bit you'll want to open a terminal, run scripts and do stuff outside flatpak) For the second point, well it's just that update are not frequent enough ? This has nothing to do with flatpak technology right ?
- dcbadacd 8y ago
  Maybe it's about time we break backwards compatibility and get rid of all dotfiles in ~ and move them to say .local/share/software_name and then start restricting access to those folders?
  - mort96 8y ago
    But I still want to be able to use my Flatpak VsCode to edit config files in .local or .config, and I still want to use my Flatpak Gimp to edit images in .local/share/icons.
    - dcbadacd 8y ago
      The chances of those things happening are rather low for the average user a prompt would solve those and would be a way better solution that just allowing full access to ~ and any dotfiles.
      - bil-elmoussaoui 8y ago
        There are a WIP portals that would instead of giving access to the whole filesystem or the whole devices list a prompt for the user to allow access to a specific device or a specific system feature. Let's take for example a Music player, you can give it access to `xdg-music` folder only. But the users will start complaining about the fact their music is stored somewhere else and they would want a full access to their home folder or to the devices list to play music from an external hard drive or whatever. Things are not perfect yeah, but many of those apps were not made with a sandboxed env in mind. There are a bunch of new apps that were created with that in mind and use those portals features. Things are getting better, slowly maybe but surely! The Flatpak packages will improve with time and we will be getting a better way of distributing apps safely and easily on Linux.
RX14 8y ago
What a lot of people are missing is that flatpaks put the flatpak author responsible for the security of every package inside the flatpak. If you use a package from an unofficial rpm or deb repo, they're nearly always still dynamically linked, so security updates for things like openssl still apply.
- linuxftw 8y ago
  > they're nearly always still dynamically linked, so security updates for things like openssl still apply. Could be, or might not be. It's easy enough to ship compiled libraries in the same rpm/deb as the software you ship, or put your defunct versions into the same unofficial repo under a different name and have your application pull from there. In fact, they might not use openssl at all, possibly some other half-baked library. Of course, that's for languages that are compiled; people can vendor in all sorts of stuff into python sources. Don't even get me started on golang. Installing software from any source involves risk. Distribution repos help mitigate some of that risk. Flatpaks as a technology don't change the risk (significantly) from a bit-rot point of view IMO.
  - cyphar 8y ago
    > Distribution repos help mitigate some of that risk. Flatpaks as a technology don't change the risk (significantly) from a bit-rot point of view IMO. I don't agree. There was a FOSDEM talk by one of my colleagues specifically about this issue, and why Flatpak is walking us backwards in terms of how packaging has worked historically[1]. Distributions are far from perfect (hell, some of them ship my packages and I'm definitely far from perfect) but they do solve real problems and going to a Windows-DLL-dump method of packaging is going in reverse. If your "package format" makes developers maintain all of their dependencies, it isn't solving the problem that most people actually want you to solve -- to be able to do less work and build on top of other people's work. By using dependencies maintained by your distribution you also get security updates and maintenance for free -- many distributions have paid security and maintenance teams that deal with precisely this. I cannot overstate how much work it is to maintain your own distribution. [1]: https://www.youtube.com/watch?v=mkXseJLxFkY https://www.youtube.com/watch?v=mkXseJLxFkY
brian_herman__ 8y ago
I dont see the point of This website if i am installing an application for example gparted it can format my drives??
bubblethink 8y ago
I don't see any real benefits to using flatpak in its current form. You get worse integration with the rest of the system, poor tools that are inferior to your system's package manager, and no real security benefits currently. What's the point of launching all these rubbish proprietary apps on the store with no real sandboxing ? It creates a false sense of security, which is worse. All the proprietary apps will do what they used to. They've just been ported to flatpak as thin wrappers. If you get the dropbox flatpak, it will continue to litter your home directory with hidden files.
- androidgirl 8y ago
  I use flatpak on my system for the fact that packages can be had there I can't get through my package manager easily and officially. That's the only selling point!
  - bubblethink 8y ago
    Yes, that's kind of true. You can get newer versions of things slightly easier. It can be major point if your distro is getting quite old (like RHEL or even xenial), but if you keep up with a 2 year cycle of distro updates like ubuntu LTS, you rarely hit that scenario.
    - androidgirl 8y ago
      That's definitely true! It's also good for smaller distros with smaller package managers. It's easier for a dev team to support just Flatpak than to bundle/petition for pacman, apt, yum, eopkg, and so on. I'd greatly prefer 'native' packages though.
  - IshKebab 8y ago
    That's a pretty huge selling point - I think it was the main reason for creating them. 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.
codedokode 8y ago
> Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions Aren't other sandboxes (like Ubuntu's Snap) the same?
- ianlevesque 8y ago
  Not on macOS.
newnewpdro 8y ago
This is what happens when you try escape "dependency hell" by turning the host into a composition of hosts-per-application. Now you have a clusterfuck of dependency islands which all need updating and have their own unique sets of CVEs and upstream release schedules and policies. It's not really flatpak-specific, this is the reality of containers (in the image/rootfs software distribution sense, not namespaces+cgroups) in general.
gbraad 8y ago
The developers are employed by Red Hat, but that does not make this a Red Hat endorsed product. It is not included in the current offering of RHEL and unlikely would be in a new(er) version as the technology is immature/not well enough tests d/proven yet for inclusion within EL. I call the usage of 'Red Hat' here clickbait and sensationalism as there is no indication within the text that shows the aforementioned non-existence of endorsement or inclusion. Note: the engineers working on Flatpak and both friends and colleagues of mine. Just concerned that the author misrepresents our employers viewpoint. We are allowed to work on side projects, but that does not make them default inclusions or endorsed.
tomc1985 8y ago
Coming out with yet another deployment format and then expecting maintainers to include you is wishful thinking
wbond 8y ago
> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode, Android Studio and Sublime Text still use unpatched git version 2.9.3. Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and no version of Sublime Text comes with git. After such inaccurate information, I can’t help but question the rest of the article.
- v8engine 8y ago
  I don't know about git integration but as for Flatpak version of Sublime Text, I found this: https://flathub.org/apps/details/com.sublimetext.three https://flathub.org/apps/details/com.sublimetext.three
  - wbond 8y ago
    Yes, it appears that the flathub maintainers have published Sublime Text under flathub. This is not an official distribution channel by us, and looking at the spec (https://github.com/flathub/com.sublimetext.three/blob/master/com.sublimetext.three.json https://github.com/flathub/com.sublimetext.three/blob/master...) it seems to rather automatically install Package Control, but also in a rather brittle way. Sigh.
    - nickik 8y ago
      If many distros and people want to use a flatpak to install software even with these drawbacks that would be a good indication that it would be worth doing upstream.
      - wbond 8y ago
        We currently provide a full complement of Linux package manager repositories, along with tarballs: https://www.sublimetext.com/docs/3/linux_repositories.html https://www.sublimetext.com/docs/3/linux_repositories.html.
        MayeulC 8y ago
p2t2p 8y ago
Trust me, nobody cares. The regular user doesn't go past "I can install Spotify in one click". It always were like that and it always will be like that. With more "normies" coming to Linux there will be more stuff like that. That is exactly why people were saying that there are no viruses on Linux only thanks to lower popularity. And with all honesty - how many of us read script files when installing something from AUR? But hey, nobody forces you to use it! You can always choose you distro repo or go DIY way.
- p2t2p 8y ago
  Downvoted without replies... Does anybody find statement that most users don’t spend too much time to ensure security of their machine offensive or incorrect? I know only myself and few other fairly geeky people doing that...
deleted 8y ago
[deleted]
emmelaich 8y ago
By default, flatpaks don't have r/w to your home. And setuid binaries have been blocked for a while (as the article says). Plus, selinux will have these things locked down on a system that uses selinux. I think the problem is part perception. Flatpak, like Docker is not primarily for security isolation. It's isolation for ease of deployment - to avoid dependency hell. Not saying Flatpak's failings are not a problem. Just keep some perspective.
megous 8y ago
What's cross-platform experience for packagers/builders? Seems like you can't do cross-compilation, so expecting upstream to provide flatpaks for users is expecting upstream to manage virtual or real machines for every [desired] CPU architecture with all the annoying host distro installation/management, networking stuff, etc.? At least with the current model, upstream developers can offload most of that to distribution packagers.
- wmf 8y ago
  In reality every desired CPU architecture is x86-64.
  - ndnxhs 8y ago
    That's not reality at all. Many laptops run ARM CPUs now. Especially on Linux.
  - megous 8y ago
    I have GNU/Linux desktops on armv7 and aarch64, and i686 laptop. So with this attitude, flatpak is mostly worthless to me.
chb 8y ago
They so don't deserve CoreOS. Pity they were able to acquire it.
djsumdog 8y ago
Ugh. This trade off again. Linux package management means you update a library once, and fix that security problem everywhere for all the apps that use that library .. except for Firefox, Libreoffice, Chrome and others which insist on packaging their own versions of libjpeg, libpng and everything under the sun for stability. A docker container contains all its own dependencies too. You gain stability .. but you could have a bedbug nest of security problems down there. I don't get the move to Flatpack and Snap for desktop apps. Desktop apps need to interact with the base OS, the display system (X11 or Wayland) the shared toolkit libraries (GTK/QT). I've screenshots of native vs Flatpack vs Snap and they tend to have different window borders, some get the GTK themes matched up while others don't. Not to mention the wasted space when every single application has its own version of everything. What, did you think electron apps each packaging their own 80MB web browser was a good idea too? This just seems like the wrong direction to move in for Linux. We're not MacOS! We don't have hacked together shit like Android apks. We need to be better than that!
- XorNot 8y ago
  Linux needs a deduplicating filesystem though in the kernel. Something to make containers and docker handle the situation of "lots of mostly identical files" well. Even ZFS, which should be good at this, really isn't.
  - dralley 8y ago
    Take a look at Fedora Silverblue with rpm-ostree, it does basically what you describe
- v_lisivka 8y ago
  In Fedora, Firefox, LibreOffice, and Chromium are contain no bundled libraries. Main offenders of "no bundled lib" rule are Go and Rust applications.
  - Conan_Kudo 8y ago
    In Fedora, Rust applications don't have bundled dependencies, but since Rust doesn't provide a stable ABI, we statically link the libraries into the application for now.
andreyv 8y ago
Flatpak, Snap, container images are the new iteration of static linking. Just like with static binaries, they make deployment easier for the developer, but introduce problems with size, duplication and library updates. Flatpak added runtimes [1] to alleviate the problem. Does this solution look familiar? Yes, it is the same dynamic library concept. We are coming full circle. [1] http://docs.flatpak.org/en/latest/available-runtimes.html http://docs.flatpak.org/en/latest/available-runtimes.html
jwildeboer 8y ago
Disclaimer: I work for Red Hat I strongly oppose these kind of attacks by people hiding their identity. No matter how valid the criticism might be, this goes against all the ethics of Open Source. Just like the Devuan folks that vigorously attacked systemd and Lennart. This must not be tolerated. Yes, I’m very upset.
- JepZ 8y ago
  Why is it problematic when people hide their identity? I mean, if the criticism is valid, what does it matter who said it? I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations.
  - jwildeboer 8y ago
    > I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations. And I think there is a strong correlation between those two things. It definitely makes it impossible to enter in a productive discussion about how flatpak could work better. The way it stands now, this rant is useless, aimed to be destructive and simply unacceptable. IMHO.
    - folknor 8y ago
      > And I think there is a strong correlation between those two things. There might be a correlation between those in this case. But just because it - perhaps (I haven't actually read the "article") - applies in this case, that's a far cry from being a general rule. Think of it in terms of - for example - a muslim speaking up against oppression in their home country, or a Tibetan speaking up against China. Should they not be allowed to do so anonymously? It is possible in most cases to judge merit on content/argument alone. It's very difficult to imply or deduce someones motive, whether you know who they are or not. In most cases, you would be mistaken. I find it helpful to remind myself that most people do what they do out of love, even if their actions are/seem utterly insane, or are/seem destructive.
nickik 8y ago
Flatpak and Flathub are not hiding this and nowhere on Flathub does it claim that all Flathub apps are securely sand boxed. Flathub has unoffical packages and this it has the same issue like all other unoffical repos. Flatpak CAN be used to do sandboxing, but that totally different from saying 'all application will be securely sandboxed'. I don't know where the authors got this idea from. The simple fact is, that sandboxing on a legacy system is difficult and Flatpak can't magic away many of the security issues in the Linux desktop. Also all the 'Red-Hat Developers' evil reminds me of the typical Systemd-hate rant and I really hope we don't have to suffer another iteration of this in the Open-Source community. The person that leads the project works for Red Hat, but its not a Red Hat project.
patal 8y ago
> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue. The flatpak release notes talk of a "minor security update", where "minor" surely means "of small size", not "of little importance" as OP would have it. Though the text could add a little importance.

377 points by stryk 8y ago

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

zeroname 8y ago
This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. 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.
- pdonis 8y ago
  > This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. True, it isn't any less broken than that; it's more broken. First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). That's by design: it should take some work on the user's part to download and install software that hasn't been vetted by their distro. Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.) Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure". Promising that your apps are sandboxed means they need to actually be sandboxed; disabling the sandbox with default privilege settings breaks that promise. So users get less security than they think they are getting with this model. > Linux is secure because nobody can ship software on it without going through massive hurdles Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.) > everybody who is smart enough to install software on Linux does some diligence. Nothing can protect a user who is not smart enough to do some due diligence before installing software. So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security.
  - zeroname 8y ago
    > First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user... There are no "average" Linux users. There's only Linux nerds and people who have had their Linux nerd friends install and maintain Linux for them. The whole "problem" is made up. > Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.) 2525 Year of the Linux Desktop > Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure". I haven't seen Flatpak touted to have a security sandbox, nowhere on their site do I see "security" being even mentioned as a feature. So that accusation is made up as far as I am concerned. > Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.) Gee, a thousand FOSS applications, what more could a user want? Have you personally ever tried to ship software for "Linux"? Do you even develop software? > So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security. It's "security by inconvenience". This has nothing to do with real security. These users you are trying to protect don't exist, but even if they did, you wouldn't protect them by making it hard for them to install software, you would be making them use Windows instead.
  - linuxftw 8y ago
    > is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). 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
    - pdonis 8y ago
stephenr 8y ago
> bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux. Wat? Windows famously doesn’t have “just drag it to your desktop” to install. There’s an entire segment of the industry around building installers and managers for installation of windows programs. And I can’t recall a single mac-affecting malware that spread the way you describe except maliciously modified versions of pirated commercial software (eg adobe stuff) which doesn’t actually install via drag and drop anyway - it has an “installer” if its own.
- ambrice 8y ago
  I think the reference is to the fact that on Windows you download some random .exe installer from some place on the internet and trust it, rather than selecting a signed package from a trusted repository that gets automatically updated. Should have been "download it, drag it to your desktop, and install it".
  - pdonis 8y ago
    Yes, this is what I was referring to. Sorry for my unclear phrasing.
Natela 8y ago
What ? No it's exactly the opposite ! I think you're confusing with AppImage maybe which is indeed download from the browser & run. 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"
- pdonis 8y ago
  > The (long) goal of flatpak is that the user would never download and execute from the browser 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.

jiveturkey 8y ago

oy. i'm not at all familiar with it but the author comes off as being on his game so i'll take it at face value. beyond disappointing that RH would release such a thing.

glglwty 8y ago

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

Kalium 8y ago
As I understand it, from reading this page it doesn't actually matter much how secure the sandbox is as many applications effectively disable it.
- briffle 8y ago
  And many docker users run privileged containers, because then they don't need to troubleshoot permissions.. It doesn't meant the underlying system is flawed, because people take the lazy way around it. 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.
  - Kalium 8y ago
    You're right! It's not the fault of the underlying system, it's the fault of the lazy people who work around it trivially. 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.
  - the_duke 8y ago
    I almost never had to run a privileged container, and I avoid it whenever possible. As far as I have seen, privileged container use is rare. What lead you to the assumption that it isn't?
    - 8y ago

Ecco 8y ago

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

TeMPOraL 8y ago
Domains are cheap. Often free for one year.
- Ecco 8y ago
  Well they’re “free” if you buy them alongside hosting. Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc...
  - TeMPOraL 8y ago
    > Well they’re “free” if you buy them alongside hosting. Depends on hosting company. I've "bought" domains for free many times, without hosting, just to run joke sites for few months.
    - Ecco 8y ago
      Ha, interesting! I always assumed a .org was at least a dollar. Mind sharing a link?
      - TeMPOraL 8y ago
        Don't have a free "org" source; maybe they never was. Free domains I got were under national TLD.
  - ReverseCold 8y ago
    > that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it 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.

vanderZwan 8y ago

> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security. Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion like this is not going to make it more likely that they admit their mistakes. A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly. [0] https://en.wikipedia.org/wiki/Hanlon%27s_razor https://en.wikipedia.org/wiki/Hanlon%27s_razor

briffle 8y ago
Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. 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. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by the developers to maintain it) In fact, it could be nicer if it catches on, as developers won't need to maintain deb files, rpm files, pacman files, etc.
- kilburn 8y ago
  > his other major gripe is that the security updates for non-official flatpaks 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.
  - geofft 8y ago
    The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. The Debian security team is a volunteer team, and it's entirely realistic that someone may actually have seen delays in the packages they care about getting security updates. "No you don't" is arrogant - you have no way of knowing that.

phaer 8y ago

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

jayrwren 8y ago
It's exactly the same state.
- niemeyer 8y ago
  No, not really. Files at ~/.* were never readable or writable for strict snaps, even when they were granted the "home" interface, precisely for that sort of reason. The file permissions and ownership are also strictly checked by the store (no setuid bit issue). Classic snaps depend on manual approval, and need to be acknowledged by the user before being installed for that reason, etc.
linappdev 8y ago
With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers. So, for example, on Fedora, Debian, CentOS, or openSUSE, snaps run in "devmode" because of the missing functionality. There's been some work over the last couple of years to upstream some of the work on AppArmor (so openSUSE may partially work in the future). There's a desire to support SELinux properly, but to date, no work has been done. There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too). Based on conversations I've had with the Snappy team before, it comes down to two things: * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to * Canonical's customers haven't demanded it of them yet I find the latter point especially strange given the constant demand for official Snappy support on CentOS and Amazon Linux 2 (which is currently not available yet). Both distributions have SELinux and rely on it for security. In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement. That is, they're not confined, and have full access to the system, they just use snapd as the delivery system for the software. So even if Snappy confinement actually worked on all Linux distributions, it doesn't matter because most apps delivered through Snappy are entirely unconfined. Finally, Canonical is the sole arbiter of snaps. You cannot use your own store with it, as snapd is hardwired to Canonical's store. They own all the namespaces, and are the sole publisher. And yet, they have a confusing policy of how they don't consider themselves the distributor of software when they are... It's strange. But because you can't run your own store, you're at their mercy for snap names, available functionality, and so on. Flatpak, in contrast, is designed to offer the fullest confinement possible with common security features in the mainline Linux kernel that all major distributions offer. Applications register what they need in their manifests, and the Flatpak system handles granting access as appropriate. Flatpak relies on federation through "portals" for interacting with the host environment, and that allows for the applications to have far less direct access than they would normally have. It's basically an Android-like setup, and it seems to work well, though it's still far too coarse for some kinds of applications. Flatpak lets you run your own repository, so you can implement whatever means you'd like for delivering them, even keyed paywall locations, so that customers who pay get their own access to their own purchases. But most apps probably should be pushed to Flathub, especially if they're free. I think no one has figured out yet how to do paid stuff. (Disclaimer: I'm a Linux app developer that grudgingly deals with both formats. I'd rather just keep using RPMs myself, as it works well and is reasonably portable.)

dralley 8y ago

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action causes a prompt. Now, that's not to say this is good as it is, but for most listed programs it's probably the way to go.

blattimwind 8y ago
File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.
- aaaaaaaaaab 8y ago
  That’s how macOS sandboxing works too.
- TeMPOraL 8y ago
  Do you open your files in PyCharm or VSCode through a file picker?
  - blattimwind 8y ago
    Drag and drop project folder. Also, yes, I do open project directories using PyCharm's (poor) file picker.
  - stephenr 8y ago
    I’d imagine once you open a directory you can open files within it (and child dirs)
  - ReverseCold 8y ago
    You open the parent project directory, right? That's how the file access controls work in MacOS. Sandboxed apps can't read files outside their sandbox until the user opens the directory/file in the file picker at least once. (Or something similar, I can't seem to find a source on that...)

jopsen 8y ago

flatpak is still early.. most apps are still installed from package managers, and few apps are written with flatpak in mind. The current situation is probably not much worse than installing from various third party package archives. I suspect things will get better as adopting catches on.. it's no surprise that early stage open source software have rough edges.

JepZ 8y ago

This is especially bad for projects like Linphone (open source SIP Client) which exclusively provide Flatpak-builds for Linux [1]. [1]: http://www.linphone.org/technical-corner/linphone/downloads http://www.linphone.org/technical-corner/linphone/downloads

confounded 8y ago
I think flatpak is probably the right choice for a phone. Assuming equal developer attention on both flatpak and deb repos, there's nothing inherently worse about flatpak. The nice thing about flatpak for a phone is that it could in the future offer something like the Android/iOS permissions interface.
- JepZ 8y ago
  Yeah, maybe I am a bit too negative about the format itself. My problem with the Flatpak only approach was that it was kinda hard to get it to run at all and it didn't work particularly well, so I ended up with putting some work into it while ending up with an unsolved problem (stable Linux desktop SIP client). So maybe this is not an inherent problem of this technology and will work better in the future.

Pica_soO 8y ago

So a secure implementation will be written, breaking everyone's code and workflow. The resulting rage of the users will then be used to silence the security concerned, and a great checkbox will be painted under the door-mat [Informed consent is given by foot stomp] and the world rotates on.

jbk 8y ago

> VLC [...] filesystem=host See my comment on why it's not easy to fully sandbox software like VLC: https://news.ycombinator.com/item?id=14409234 https://news.ycombinator.com/item?id=14409234 The author is correct, in the fact that flatpak-vlc is not a secure sandbox.

laurent123456 8y ago
Thanks for sharing the info. I'm just curious - how would splitting VLC into multi processes solve the permission issue, since the sub-processes will still need access anyway?
- jbk 8y ago
  Each subprocess would only get one permission, the one that it actually need. The critical parts (audio decoders, video decoders, parsers) would not get access to $HOME or network, for example.
  - laurent123456 8y ago
    Thanks, that makes sense.

zeroname 8y ago

"Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it." No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects flatpak and literally every other form of installing those same programs outside of a sandbox.

audidude 8y ago
If we could get applications to switch to using APIs backed by the xdg-desktop-portal, then they don't even get access to the host/home filesystems. They talk to a service which sends a FUSE FD to the app, and that overwrites the original file when close()d (but never does the app get direct filesystem access). 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.
iforgotpassword 8y ago
Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not. A flatpack sharing any part of the host file system with the app should be marked as insecure when installing and/or launching.
- zeroname 8y ago
  > Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not. It is isn't being sold as "secure". It's sandboxed in the same way that Python virtual environment is sandboxed, i.e. you're not messing with the system software installation. Real security sandboxing is a completely orthogonal feature that package managers do not deliver either.
  - irishsultan 8y ago
    Honestly, that's not what I would expect sandboxed to mean. By that definition installation in /opt/$vendor/$software/$version would also be sand-boxed.

ktpsns 8y ago

To be honest, this security nightmare also covers other contemporary "container" formats such as docker. Running docker containers as a non-root user is unfortunately still not a widespread practice. That means that any root process within a docker container has root on the host.

viraptor 8y ago
Only if you run with no isolation / user namespace. And even without that, you need to run with `--privileged` to get access to interesting capabilities. It's not as simple as container root == host root.
- yrro 8y ago
  Are user namespaces enabled by default, or are they something that you have to enable and then spend time dealing with all the containers that weren't written with them in mind?

anon_cow1111 8y ago

Random mint 18.04 user here. I just noticed about a week ago that flatpak was downloading huge amounts of data (like hundreds of MBs). I had all system updates set to download and install manually, and hadn't installed anything new for at least a month. All this data was getting sent to /var/tmp as flatpak-cache folders. I don't know what it was doing but I've since turned it off in the startup list. Any ideas? What are the chances this was malicious?

c487bd62 8y ago
I'm not a flatpaker but maybe it was updating the runtimes? http://docs.flatpak.org/en/latest/available-runtimes.html http://docs.flatpak.org/en/latest/available-runtimes.html Honestly I would be more worried about running mint (a topic not suited for this thread, a quick search would probably show you what I've read about it in the past).

nickysielicki 8y ago

1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged. 2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub. 3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a package to make sure that permissions are perfect. There is no reason that these issues can't be ironed out going forward.

aritmo 8y ago
But Flathub is flatpak. Also, does flatpak have the full support of redhat?
- Natela 8y ago
  No. Flathub has nothing to do with flatpak technology itself. Flathub is just one server hosting some flatpack repos. It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many other you could add to get your apps
  - int_19h 8y ago
    Isn't the whole point of Flatpak to prevent the same app from being packaged multiple times for different distros?
    - Natela 8y ago
      Ideally , Firefox would be downloaded from official Mozilla Flatpak repo, Blender from Blender Flatpak repo on Blender server, etc... And we would have this list of those repo on our distro. However because the official adoption is slow (very few software have official flatpak repo), flathub allowed the community to build packages themselves. But this is clearly not how it should be. The second (more legit) reason of flathub is that small developer might not want to pay a server to host their app and flathub proposes to host their repo.
- 8y ago

Natela 8y ago

The sandbox is in a sense working, the problem is that the folder the app accesses is more critical than what the user thought. We should make sure nothing in home will get executed : no bashrc, no scripts, no executable. In the "ideal" world you would never download & run any script or any executable (like on Android or IOS). Everything the user should be able to do is install or run flatpak apps. (Of course in practice as soon as you are programming a bit you'll want to open a terminal, run scripts and do stuff outside flatpak) For the second point, well it's just that update are not frequent enough ? This has nothing to do with flatpak technology right ?

dcbadacd 8y ago
Maybe it's about time we break backwards compatibility and get rid of all dotfiles in ~ and move them to say .local/share/software_name and then start restricting access to those folders?
- mort96 8y ago
  But I still want to be able to use my Flatpak VsCode to edit config files in .local or .config, and I still want to use my Flatpak Gimp to edit images in .local/share/icons.
  - dcbadacd 8y ago
    The chances of those things happening are rather low for the average user a prompt would solve those and would be a way better solution that just allowing full access to ~ and any dotfiles.
    - bil-elmoussaoui 8y ago
      There are a WIP portals that would instead of giving access to the whole filesystem or the whole devices list a prompt for the user to allow access to a specific device or a specific system feature. Let's take for example a Music player, you can give it access to `xdg-music` folder only. But the users will start complaining about the fact their music is stored somewhere else and they would want a full access to their home folder or to the devices list to play music from an external hard drive or whatever. Things are not perfect yeah, but many of those apps were not made with a sandboxed env in mind. There are a bunch of new apps that were created with that in mind and use those portals features. Things are getting better, slowly maybe but surely! The Flatpak packages will improve with time and we will be getting a better way of distributing apps safely and easily on Linux.

RX14 8y ago

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

linuxftw 8y ago
> they're nearly always still dynamically linked, so security updates for things like openssl still apply. Could be, or might not be. It's easy enough to ship compiled libraries in the same rpm/deb as the software you ship, or put your defunct versions into the same unofficial repo under a different name and have your application pull from there. In fact, they might not use openssl at all, possibly some other half-baked library. Of course, that's for languages that are compiled; people can vendor in all sorts of stuff into python sources. Don't even get me started on golang. Installing software from any source involves risk. Distribution repos help mitigate some of that risk. Flatpaks as a technology don't change the risk (significantly) from a bit-rot point of view IMO.
- cyphar 8y ago
  > Distribution repos help mitigate some of that risk. Flatpaks as a technology don't change the risk (significantly) from a bit-rot point of view IMO. I don't agree. There was a FOSDEM talk by one of my colleagues specifically about this issue, and why Flatpak is walking us backwards in terms of how packaging has worked historically[1]. Distributions are far from perfect (hell, some of them ship my packages and I'm definitely far from perfect) but they do solve real problems and going to a Windows-DLL-dump method of packaging is going in reverse. If your "package format" makes developers maintain all of their dependencies, it isn't solving the problem that most people actually want you to solve -- to be able to do less work and build on top of other people's work. By using dependencies maintained by your distribution you also get security updates and maintenance for free -- many distributions have paid security and maintenance teams that deal with precisely this. I cannot overstate how much work it is to maintain your own distribution. [1]: https://www.youtube.com/watch?v=mkXseJLxFkY https://www.youtube.com/watch?v=mkXseJLxFkY

brian_herman__ 8y ago

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

bubblethink 8y ago

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

androidgirl 8y ago
I use flatpak on my system for the fact that packages can be had there I can't get through my package manager easily and officially. That's the only selling point!
- bubblethink 8y ago
  Yes, that's kind of true. You can get newer versions of things slightly easier. It can be major point if your distro is getting quite old (like RHEL or even xenial), but if you keep up with a 2 year cycle of distro updates like ubuntu LTS, you rarely hit that scenario.
  - androidgirl 8y ago
    That's definitely true! It's also good for smaller distros with smaller package managers. It's easier for a dev team to support just Flatpak than to bundle/petition for pacman, apt, yum, eopkg, and so on. I'd greatly prefer 'native' packages though.
- IshKebab 8y ago
  That's a pretty huge selling point - I think it was the main reason for creating them. 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.

codedokode 8y ago

> Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions Aren't other sandboxes (like Ubuntu's Snap) the same?

ianlevesque 8y ago
Not on macOS.

newnewpdro 8y ago

This is what happens when you try escape "dependency hell" by turning the host into a composition of hosts-per-application. Now you have a clusterfuck of dependency islands which all need updating and have their own unique sets of CVEs and upstream release schedules and policies. It's not really flatpak-specific, this is the reality of containers (in the image/rootfs software distribution sense, not namespaces+cgroups) in general.

gbraad 8y ago

The developers are employed by Red Hat, but that does not make this a Red Hat endorsed product. It is not included in the current offering of RHEL and unlikely would be in a new(er) version as the technology is immature/not well enough tests d/proven yet for inclusion within EL. I call the usage of 'Red Hat' here clickbait and sensationalism as there is no indication within the text that shows the aforementioned non-existence of endorsement or inclusion. Note: the engineers working on Flatpak and both friends and colleagues of mine. Just concerned that the author misrepresents our employers viewpoint. We are allowed to work on side projects, but that does not make them default inclusions or endorsed.

tomc1985 8y ago

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

wbond 8y ago

> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode, Android Studio and Sublime Text still use unpatched git version 2.9.3. Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and no version of Sublime Text comes with git. After such inaccurate information, I can’t help but question the rest of the article.

v8engine 8y ago
I don't know about git integration but as for Flatpak version of Sublime Text, I found this: https://flathub.org/apps/details/com.sublimetext.three https://flathub.org/apps/details/com.sublimetext.three
- wbond 8y ago
  Yes, it appears that the flathub maintainers have published Sublime Text under flathub. This is not an official distribution channel by us, and looking at the spec (https://github.com/flathub/com.sublimetext.three/blob/master/com.sublimetext.three.json https://github.com/flathub/com.sublimetext.three/blob/master...) it seems to rather automatically install Package Control, but also in a rather brittle way. Sigh.
  - nickik 8y ago
    If many distros and people want to use a flatpak to install software even with these drawbacks that would be a good indication that it would be worth doing upstream.
    - wbond 8y ago
      We currently provide a full complement of Linux package manager repositories, along with tarballs: https://www.sublimetext.com/docs/3/linux_repositories.html https://www.sublimetext.com/docs/3/linux_repositories.html.
      - MayeulC 8y ago

p2t2p 8y ago

Trust me, nobody cares. The regular user doesn't go past "I can install Spotify in one click". It always were like that and it always will be like that. With more "normies" coming to Linux there will be more stuff like that. That is exactly why people were saying that there are no viruses on Linux only thanks to lower popularity. And with all honesty - how many of us read script files when installing something from AUR? But hey, nobody forces you to use it! You can always choose you distro repo or go DIY way.

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

deleted 8y ago

[deleted]

emmelaich 8y ago

By default, flatpaks don't have r/w to your home. And setuid binaries have been blocked for a while (as the article says). Plus, selinux will have these things locked down on a system that uses selinux. I think the problem is part perception. Flatpak, like Docker is not primarily for security isolation. It's isolation for ease of deployment - to avoid dependency hell. Not saying Flatpak's failings are not a problem. Just keep some perspective.

megous 8y ago

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

wmf 8y ago
In reality every desired CPU architecture is x86-64.
- ndnxhs 8y ago
  That's not reality at all. Many laptops run ARM CPUs now. Especially on Linux.
- megous 8y ago
  I have GNU/Linux desktops on armv7 and aarch64, and i686 laptop. So with this attitude, flatpak is mostly worthless to me.

chb 8y ago

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

djsumdog 8y ago

Ugh. This trade off again. Linux package management means you update a library once, and fix that security problem everywhere for all the apps that use that library .. except for Firefox, Libreoffice, Chrome and others which insist on packaging their own versions of libjpeg, libpng and everything under the sun for stability. A docker container contains all its own dependencies too. You gain stability .. but you could have a bedbug nest of security problems down there. I don't get the move to Flatpack and Snap for desktop apps. Desktop apps need to interact with the base OS, the display system (X11 or Wayland) the shared toolkit libraries (GTK/QT). I've screenshots of native vs Flatpack vs Snap and they tend to have different window borders, some get the GTK themes matched up while others don't. Not to mention the wasted space when every single application has its own version of everything. What, did you think electron apps each packaging their own 80MB web browser was a good idea too? This just seems like the wrong direction to move in for Linux. We're not MacOS! We don't have hacked together shit like Android apks. We need to be better than that!

XorNot 8y ago
Linux needs a deduplicating filesystem though in the kernel. Something to make containers and docker handle the situation of "lots of mostly identical files" well. Even ZFS, which should be good at this, really isn't.
- dralley 8y ago
  Take a look at Fedora Silverblue with rpm-ostree, it does basically what you describe
v_lisivka 8y ago
In Fedora, Firefox, LibreOffice, and Chromium are contain no bundled libraries. Main offenders of "no bundled lib" rule are Go and Rust applications.
- Conan_Kudo 8y ago
  In Fedora, Rust applications don't have bundled dependencies, but since Rust doesn't provide a stable ABI, we statically link the libraries into the application for now.

andreyv 8y ago

Flatpak, Snap, container images are the new iteration of static linking. Just like with static binaries, they make deployment easier for the developer, but introduce problems with size, duplication and library updates. Flatpak added runtimes [1] to alleviate the problem. Does this solution look familiar? Yes, it is the same dynamic library concept. We are coming full circle. [1] http://docs.flatpak.org/en/latest/available-runtimes.html http://docs.flatpak.org/en/latest/available-runtimes.html

jwildeboer 8y ago

Disclaimer: I work for Red Hat I strongly oppose these kind of attacks by people hiding their identity. No matter how valid the criticism might be, this goes against all the ethics of Open Source. Just like the Devuan folks that vigorously attacked systemd and Lennart. This must not be tolerated. Yes, I’m very upset.

JepZ 8y ago
Why is it problematic when people hide their identity? I mean, if the criticism is valid, what does it matter who said it? I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations.
- jwildeboer 8y ago
  > I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations. And I think there is a strong correlation between those two things. It definitely makes it impossible to enter in a productive discussion about how flatpak could work better. The way it stands now, this rant is useless, aimed to be destructive and simply unacceptable. IMHO.
  - folknor 8y ago
    > And I think there is a strong correlation between those two things. There might be a correlation between those in this case. But just because it - perhaps (I haven't actually read the "article") - applies in this case, that's a far cry from being a general rule. Think of it in terms of - for example - a muslim speaking up against oppression in their home country, or a Tibetan speaking up against China. Should they not be allowed to do so anonymously? It is possible in most cases to judge merit on content/argument alone. It's very difficult to imply or deduce someones motive, whether you know who they are or not. In most cases, you would be mistaken. I find it helpful to remind myself that most people do what they do out of love, even if their actions are/seem utterly insane, or are/seem destructive.

nickik 8y ago

Flatpak and Flathub are not hiding this and nowhere on Flathub does it claim that all Flathub apps are securely sand boxed. Flathub has unoffical packages and this it has the same issue like all other unoffical repos. Flatpak CAN be used to do sandboxing, but that totally different from saying 'all application will be securely sandboxed'. I don't know where the authors got this idea from. The simple fact is, that sandboxing on a legacy system is difficult and Flatpak can't magic away many of the security issues in the Linux desktop. Also all the 'Red-Hat Developers' evil reminds me of the typical Systemd-hate rant and I really hope we don't have to suffer another iteration of this in the Open-Source community. The person that leads the project works for Red Hat, but its not a Red Hat project.

patal 8y ago

> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue. The flatpak release notes talk of a "minor security update", where "minor" surely means "of small size", not "of little importance" as OP would have it. Though the text could add a little importance.