20 ms·

Flatpak – a security nightmare – 2 years later (2020)

316 points by URfejk 6y ago

ampdepolymerase 6y ago
What is the security story for Snap and AppImage?
- littlestymaar 6y ago
  AppImage is a convenience layer which doesn't claim to add any security as it provides no sandboxing whatsoever. And the outdated dependencies in images are likely to exist in the AppImage world too.
  - PhilippGille 6y ago
    The AppImage website mentions Firejail as a way to sandbox apps. https://firejail.wordpress.com/documentation-2/appimage-support/ https://firejail.wordpress.com/documentation-2/appimage-supp...
Quickshooter 6y ago
Snaps for services, debs for user apps
- batrat 6y ago
  you hurt all 9 pacman's out there.
- loloquwowndueo 6y ago
  Snaps suck for services because they auto-update and either restart daemons without warning or leave the running process in an undefined state.
nodja 6y ago
All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?
- littlestymaar 6y ago
  Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?
  - mavhc 6y ago
    Passing responsibility of not distributing evil software from the gatekeepers to the user. Ignores half the point of having a distribution that has a package manager, curated software.
    - oblio 6y ago
      So the solution is to have the package manager decide things for every user?
      - diffeomorphism 6y ago
        Yes, the point is to have the package manager set sane defaults for every user. Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all. A much more sane approach would be to enable access to ~/videos and other reasonable places at install time and only ask for additional permission when needed.
        lokedhs 6y ago
        Flatpak allows this, but requires changers to the application so that it calls the correct API's when requesting files outside of the allowed directories. The article does highlight some actual issues, but the author implies that the solution is to simply not use it at all and go back to the free for all smörgåsbord of access rights that an application installed from the regular repositories have. Personally, I consider Flatpak the best solution available right now time minimise the attack surface for anyone not willing yo go all the way and run Qubes OS. If there is a better alternative I'd be happy to hear it, since I cannot run Qubes one of my machines.
danieldk 6y ago
Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
- littlestymaar 6y ago
  Interesting part: > It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful. […] They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portals instead of direct home or host filesystem access without losing functionality. Which means that the author still has a point: there are still lots of use cases where the only practical way to use the file-access sandbox is to disable it. Btw, the post you shared is a much more balanced view on Flatpack than the OP, but after having read it I would still consider Flatpack not being ready for what it advertises.
  - santoshalper 6y ago
    It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.
    - andrey_utkin 6y ago
      It must not be all or nothing. In firewalls we have rules. In SELinux etc we have rules, and distros package them for you.
      - akvadrako 6y ago
        What kind of rule are you talking about? Flatpak is pretty flexible.
mands 6y ago
Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.
- ekianjo 6y ago
  note that the response partially agrees with the points raised, it looks like a constructive discussion overall.
  - nextlevelwizard 6y ago
    It is hard to guess at motives when author is unknown. Or when neither of the CVE links go anywhere. Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages. With ffmpeg I don't know if things like Chromium are actually using the flatpak ffmpeg or if they ship with their own libs.
    - eis 6y ago
      Which is good as one should discuss the merits of the arguments brought forth when discussing the pros and cons of a technology rather than who who said it or what motives they might have. Edit: when I wrote this comment only the first sentence of the parent existed.
    - necovek 6y ago
      You've misunderstood "how Flatpaks work": they are using the same system calls that containers use for containerization but in a different way, look at https://en.wikipedia.org/wiki/Linux_namespaces https://en.wikipedia.org/wiki/Linux_namespaces (Snaps use AppArmor too if that's a more familiar technology). They are not containers in themselves: if you feel this is pedantic, the way namespaces are used can make all the difference (eg. why you should not be running stuff in docker containers as root which can easily be used to get root on the host).
dastx 6y ago
One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted). We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.
- foobar33333 6y ago
  I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it. The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.
  - Iolaum 6y ago
    > This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.
    - foobar33333 6y ago
      If the package has host fs access, the sandbox is essentially turned off. A few packages have this because they just don't work without it. The thing is, clickbait bloggers go nuts over this but the state is not any worse than if you had used a .deb The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing. I am certain this is not an intentional misleading feature because Gnome Software is hardly functional and need serious work across the entire program.
hkt 6y ago
Is there a security comparison somewhere of all the new fangled ways of getting up to date desktop software on Linux? snaps etc too? I suppose the real answer may always have been backports on debian distros - which is to say, trusted sources over technical solutions.
- eeZah7Ux 6y ago
  Spot on.
- danieldk 6y ago
  which is to say, trusted sources over technical solutions This does not solve the problem where your a PDF reader from a trusted repository happens to have a zero day exploit. When it is exploited, the attacker could have access to all your files, since there are no further limitations unless you bubblewrap or firejail the application yourself. Since sandboxing is one of the goals of Flatpak, the exploit would be limited to the sandbox (if sandboxing was enabled for the PDF reader).
  - hkt 6y ago
    It doesn't solve that problem, but it does provide a channel that is likely to receive an update in most distributions. It would be nice to not have to choose between sandboxing and security updates, though.
    - danieldk 6y ago
      I agree, but nobody seems to be really working on (user-friendly) sandboxing of applications distributed through traditional package managers. You can use Firejail or bubblewrap, but they are not exactly user-friendly solutions.
cl3misch 6y ago
All Linux users I know don't use Flatpack/Snap for their sandbox, but much rather for getting the newest version of some UI app (Inkscape) on an older Ubuntu release. I think this shows that a standard release cycle is not appropriate for desktop users.
- sjellis 6y ago
  Yes, for me the sandboxing is not the immediate benefit. The instant value is providing channels for developers to ship apps to their users without either side having to mandate the OS that the other uses. Right now, even well-funded projects like Visual Studio Code have to pick and choose which Linux distributions and versions that they package for. They don't provide packages to the main repositories for Linux distributions, partly because the release cycles are so wildly different. I don't want Debian stable to ship a completely new base system every few weeks, but the release cycle of my Web browser is a new version every six weeks. In the ideal Flatpak world, I can run Solus or whatever distribution I choose, and the app developers that I rely on can not care about distribution market share, and just target Flatpak runtimes. The challenge is going to be to ensure that Flatpak repositories and the Canonical App Store (the server end of snap) enforce good enough legal and security checks once vendors have started using them.
jart 6y ago
Am I the only one who sees the irony in it being a scandal for free software to fail to adequately restrict freedom? I just can't imagine an iPhone style restrictions model ever gaining momentum in open source. As much of a prize an App Store would be, it's just too at odds with the culture. I think what makes more sense for open source is to have better tools for monitoring what it's doing. The behavior of some of these programs with things like dns is like the hunger games and you can't trust the system to save you with a top-down permissions model when the system itself is the problem.
- e_proxus 6y ago
  Security and open source philosophy are two completely orthogonal problems. You can a have an open source system that is the most secure, sandboxed implementation there is. Likewise you can have a completely insecure closed source proprietary system. The freedom in open source could be the freedom to structure your system in the most secure way possible for running untrusted applications. It’s just that no one managed to achieve this yet in a satisfying way.
  - jart 6y ago
    Not entirely. A few months ago I was reading about a controversy where the Emacs dev team was concerned about the ethics of conducting an online survey. Can you believe that? That's why I like using their software. You just know people who are that extreme philosophically will never in a million years betray you. Don't you think tools like Bochs, QEMU, gVisor, etc. are reasonably satisfying? Security is a hard problem since there's an endless push and shove around its tradeoffs hence why sometimes the best one can afford is monitoring.
- psanford 6y ago
  I see flatpak and snap as potential solutions to the problem of distributing proprietary software to Linux. Its in that usecase that I really want sandboxing and where the current solutions are lacking. Right now I'm most happy with Firejail for sandboxing proprietary applications. It doesn't solve the packing problem but seems to do the best job at actually limiting what applications can do.
jeppesen-io 6y ago
Shall I plug NixOS?
- xvector 6y ago
  What is Nix and why is it a better alternative?
  - danieldk 6y ago
    There is some overlap and there are a lot of differences. One point of overlap is that Nix makes it easy to install packages that are newer than your os. For example, you could run NixOS 20.09 or Ubuntu 16.04 and have the latest Handbrake or youtube-dl. A large difference it that Flatpak also attempts to sandbox applications, which Nix doesn't (it only sandboxes builds). Though it might be easier to sandbox applications using Nix than traditional package managers, since all dependencies are made explicit.
    - mlinksva 6y ago
      There's a larger amount of overlap with https://spectrum-os.org/ https://spectrum-os.org/ (which builds on Nix). https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland/ https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kv... is also really interesting (and discusses Nix and SpectrumOS) and itself was discussed at https://news.ycombinator.com/item?id=26378854 https://news.ycombinator.com/item?id=26378854
  - kaba0 6y ago
    Basically, nix (and guix, which is based on it) is the only package manager that actually solves the dependency hell problem properly. It makes builds reproducible, and basically a package will depend on it’s inputs’ hashes. So you can not only install multiple versions of the same package that is solved by some package managers although in hacky ways, you can install multiple ones that only differ in eg which libc version they link to. In this way, I do think that it is truly revolutionary - but it is a package manager (and NixOS makes basically the OS a big package). Flatpak and snap try to do this as well, in an objectively worse way, but they also provide different features, so they are not in competition. I would rather like to see flatpak and snap employ nix for solving the package management problem and build on top of it. That would actually make the linux solution better than what we have on other OSs.
fguerraz 6y ago
My most recent favourite https://gitlab.gnome.org/GNOME/mutter/-/issues/1606 https://gitlab.gnome.org/GNOME/mutter/-/issues/1606 In this case more of a gnome issue maybe, but the fact that there's no UI feedback from either flatpack or gnome is laughable.
deleted 6y ago
[deleted]
mrweasel 6y ago
Security updates are a huge issue for most “container” formats. Even official image on Docker Hub receive almost zero security updates and most companies seem to have no policy on how to keep container, be it Flatpak, Docker or even LXC containers updated.
- antimba 6y ago
  > Even official image on Docker Hub receive almost zero security updates Are you talking about the Official Images program? Because if so, this is not true.
cardanome 6y ago
I don't need the security. I don't need automatic updates. As a Linux user, most of my software will be installed with my native package manger and receive the appropriate security updates. Flatpak/Snap/Appimage are just for when the former option is not possible because the software is not available or not in the right version I need. I am making a conscious decision here to seek out that software and can be expected to check for trustworthiness. The Windows world survived decades with running random .exe files from the internet. Some people got hurt but that is fine. Sometimes convenience and productivity can be more important than security. I already have a good sandboxed environment, it is called a web browser. So really for me the only thing I need is some easy way to run an application with just a single click on any Linux system. Appimage works fine for me. All the other features, I don't need them.
LockAndLol 6y ago
"People are trying to do things better, I'll say they aren't and not provide a single option that's better" aka "I'll complain about stuff and not do a single thing to improve it". What a contribution. Typical flame bait website.
cheph 6y ago
> The sandbox is STILL a lie No it is not. If sandboxed means no access to filesystem, sure it would be, but that is not the only definition of sandboxed, that is not the definition of that under which flatpak said they would operate, that is not the definition of sandboxed under which other things operate. If you want them to use a different definition of sandboxed, by all means submit an issue making the case, but you don't even make it here. You just ignore that and then proceed to act as if your definition is the only reasonable one. And if that was the case the very least you can do is find a reference for your definition. Try harder with the FUD.
- vntok 6y ago
  A single line of code allows any "sandboxed" program to escape from the sandbox. This is not what the word "sandboxed" means for any reasonable definition of "sandboxed".
  - cheph 6y ago
    > A single line of code allows any "sandboxed" program to escape from the sandbox. How is that what is happening here?
Shadonototro 6y ago
it doesn't matter what people think both snap/flap user experience is trash linux desktop is doomed to fail people the people who make decisions are clueless and tasteless
- preommr 6y ago
  linux desktop is never going to take off and died off when all the money moved to the cloud - it's not the 2000s, you can download windows and run it for free because that's not where the money is anymore. For the average user that's not technically oriented, that's going to be their goto solution.
  - supernintendo 6y ago
    > linux desktop is never going to take off Who cares? Why is popularity so important to you?
- Jonnax 6y ago
  What's your idea that would save Linux desktop?
  - Shadonototro 6y ago
    less fragmentation, i think Unity 8 could have been the answer, sadly it died way to early..
- pjmlp 6y ago
  The Linux Desktop has failed already thanks to the endless fragmentation and religious attacks on drivers. Even ChromeOS and Android only package the Linux kernel, while building their own userspace on top. With the Web turning into ChromeOS, and the return of timesharing via the cloud, there is even less reasons to care about the GNU/Linux desktop.
- supernintendo 6y ago
  > linux desktop is doomed to fail What does this even mean? I’ve been using Arch Linux with KDE as my only desktop OS for years and it’s a wonderful time. If you think Windows is better and prefer to use that, great. I personally prefer Linux and a lot of other people do as well.
krick 6y ago
I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, and a number of tools installed via pip or directly downloaded from github. (In fact, you probably use Linux on desktop in order to do all these things, because it makes life easier.) And many users aren't even really aware of the contents of their .bashrc and such. So, is there a security problem with Linux desktop? Yes, absolutely. And it is serious enough to worry for those who are not paranoid security enthusiasts (I mean, even real vulnerabilities aren't truly a concern to many users, but we have to admit there is a problem, when it becomes quite evident, that Linux starts falling behind both MacOS and Windows in this regard). But is flatpak the culprit? No, not really. Linux on desktop in 2021 is just really flawed (at least security-wise).
- syockit 6y ago
  I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?
  - my123 6y ago
    For Windows, there are the Win32 apps that you talk about, which aren't sandboxed. And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.
    - pjmlp 6y ago
      Win32 applications can also be sandboxed, when packaged as MSIX. Windows 10X original roadmap was to merge both sandbox models, and it is also part of Project Reunion goals.
  - 6y ago
airhead969 6y ago
And this is why I use Qubes and not Snap, Flatpak, or any of these other cobbled-together emperors-new-clothes app package managers. I knew this would happen from the very beginning but as usual, most software developers just shrug it off.
thecureforzits 6y ago
LOL. It's so easy to troll Linux users. Anonymous websites are a neat way to do it.
pedro2 6y ago
For me Flatpak is akin to Arch’s AUR. As such, rebuilding Flatpak and its various layers should be easily rebuilt from source or equivalent as available as an option (but not the default). That would prevent some of the issues. It would also introduce bugs, but at least you would have the option.
pjfin123 6y ago
I don't have anything against Flatpak but maintain a Snap package and think Snap has made a lot of good design decisions even if it still has rough edges. For a basic application it's pretty easy to package for Snap. A lot of the things that bother Linux power users like polluting their mounted file systems wouldn't matter to regular users. My understanding is they support either pre-declaring permissions or requesting them at run time. https://github.com/argosopentech/argos-translate https://github.com/argosopentech/argos-translate
zajio1am 6y ago
Hot take: Per-application sandboxing is (in general) fundamentally flawed idea, as applications are just tools to manipulate data, while data needs to be protected from unintended manipulations, but such protection should not encumber intended manipulations. What manipulation is intended depends on worflow, not application. Such setup can work on phones due to their limited use cases, but not on desktop. What we need are tools for per-workflow sandboxing. Assign each data to worflow/project (with separate uid), and then execute applications as a part of the project. So applications would have access to data of the project in which they are executed.
- higerordermap 6y ago
  The world doesn't work like that. 1) application sandboxing isolates different vendor's code, some of which may be security / privacy infringing. 2) There wouldn't be a problem with data sharing in a properly designed sandboxing system. There will be shared filesystem, file chooser / save dialogues so that's not really a problem.
TheMagicHorsey 6y ago
It seems like some of OP's criticisms of Flatpak are not actually criticisms of Flatpak, but rather criticisms of the way Linux works. Perhaps OP would be happier with a capabilities-based operating system (like Google's new Fuschia system). It just seems like these complaints leveled against Flatpak are asking the authors to achieve nearly impossible goals given the complexity of doing sandboxing at the app level in Linux.
vorticalbox 6y ago
> The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed. All of these require access to the users data to actually function. GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media these apps have the same "problem" in snap requiring --classic to allow access to the users files.
- andagainagain 6y ago
  Question then - does flatpak require an explicit flag when installing them to access those files? Or is it as I assumed just "flatpak install"
  - vorticalbox 6y ago
    I actually believe it's set in the flatpack, though I am unsure.
KerrickStaley 6y ago
A small nit about an aside in the article: Is fcitx "the" East Asian IME for Linux? As a speaker of Chinese as a second language, I use IBus (with libpinyin), which is supported out-of-the-box in GNOME and seems to provide a better user experience than fcitx the last time I checked (which was probably 10 years ago).
raffraffraff 6y ago
Semi-related. I wanted to run Amarok 1.4 recently (because I had been having a discussion about how no music player on Linux touches MusicBee, and the last one that had promise, before the developers lost their minds, was Amarok 1.4 - yes I know about Clementine etc but MusicBee still wipes the floor with all of them. This is a digression). Anyway, I spent about an hour attempting to get get it to run on my up-to-date Mint laptop. Now, Amarok 1.4 is 12 years old, so if you want to get it to run, you'll either have to compile it (which means getting your hands on the 12 year old KDE libs), run a 12 year old Linux distribution in a VM, or... Dockerize it. Now you see where the flatpak connection comes in. Step 1: Find an Ubuntu 8.10 ISO and mounted it: sudo mount -o loop ubuntu-8.10-desktop-amd64.iso /mnt/intrepid Step 2: Unqsquash the filesystem: sudo apt-get install -y squashfs-tools sudo unsquashfs -f -d /tmp/unsquashfs /mnt/intrepid/casper/filesystem.squashfs Step 3: Import the tarball into a Docker image: sudo tar -C /tmp/unsquashfs -c . | docker import - ubuntu/intrepid Step 4: Run interactively and install Amarok: docker run -it --entrypoint=/bin/bash ubuntu/intrepid (NOTE: At this point, it was pretty hard to find an apt repo for Ubuntu 8.10 but, amazingly, one or two still exist online. So I edited the apt sources, ran apt-get update && apt-get install -y amarok. I also created a user to run Amarok - one whose uid/gid matched my own user. These commands are left as an exercise for the reader) So I dockerized Amazok 1.4.10 / Ubuntu 8.10. What next? Well, I could have created a Dockerfile that started "FROM ubuntu/intrepid" and repeated all of my manual work I did in the interactive container, but I'm not keeping this thing, so I just did this the hacky way: docker export quirky_mendel -o ubuntu_intrepid_amarok.tar docker import intrepid_amarok.tar amarok:1.4.10 Now I have a docker image called "amarok:1.4.10" which I can share on Docker Hub! Does it work? docker run -it --entrypoint=/usr/bin/amarok --rm --name amarok --net=host --user amarok --privileged -e DISPLAY=:0 -v ${HOME}/.Xauthority:/home/amarok/.Xauthority amarok:1.4.10 IT WORKS! A 12 year old music player running in a docker container on the latest Linux Mint. My alternative to Flatpak / Snap etc. Is it safe? Nope! It's running in an Ubuntu image that wasn't updated since 2008.
superkuh 6y ago
Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically compile or run software written today. That's okay for mega-corps who re-build the entire software universe every time they want to make a change. Or for those who ignore desktop entirely and just "deploy" containers. And that's lead us to today. Linux desktop can't live for more than a few years on it's own. In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. But this doesn't fix the futureshock. It only makes things for desktop users worse.
- busterarm 6y ago
  I only use Flatpak apps when it's my only option and the only places that seems to be are Electron apps. Discord & Slack, I'm looking at you. I also run a rolling-release distribution...
- GekkePrutser 6y ago
  Indeed, very good point. Those is why I moved to freebsd for my desktop. Too many corporate interests hijacking Linux right now.
- einpoklum 6y ago
  > Containers on the desktop are a symptom of a festering underlying disease. Agreed, although we may be in disagreement regarding what the disease is. > Modern Linux development is extremely rapid pace I believe you are over-generalizing, both over different distributions and over different packages within a distribution. > and is 100% targeted at the needs of the corporate entities paying for the development. ... specifically, many distributions are not funded by one, or a few, specific entities, corporate or otherwise. Debian comes to mind. I've never felt its is developed rapidly, or that languages change that quickly. > . Linux desktop can't live for more than a few years on it's own I'm not sure what you mean. > In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. but the rest haven't.
andagainagain 6y ago
One thing that gets me about the sandbox of flatpak is that it doesn't seem to be up to the user. If the developer of the app chooses the permissions, then there isn't a fundamental difference for security from having all permissions anyways. Ideally a user installs the app and they would know, without reading anything else about the app, that the app is separate from their system. If any app you install is NOT separate from the system, then... the sandbox is like making a giant wall but having a door right in the middle of it.
- takluyver 6y ago
  You're thinking about malicious apps, where the developer would just request all permissions they can. But sandboxing is also about limiting the impact of security issues in apps from honest, well meaning developers who (hopefully) won't request more permissions than they need. E.g. if I make a chat app, and it has a bug that lets someone send you a malicious message and execute code in the app, then a sandbox is a really good thing. The developer also sets the default permissions - in principle, the user can change these before running the app. Of course, not many users will do that, but there are still cases where it can make a difference.
GekkePrutser 6y ago
From the article: > The flatpak runtimes and apps do not get security updates This is exactly what I worry about with things like Flatpak and Snaps (Ubuntu). Instead of having the distro maintainer provide timely security updates, all they have to do now is shrug and point at the external package maintainer. So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. This is clearly not going to work as well. And while sandboxing is a great idea, it can be done using other methods too, like SELinux or AppArmor. Not to mention the wasting of resources by running all those separate versions of each library.. But that's not security-related discussion.
- antimba 6y ago
  > So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there. [1]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/bootstrap/openssl.bst https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/ma...
  - GekkePrutser 6y ago
    Ok bad example then, and I didn't know that, but most libs are not part of the runtime :) I just mentioned openssl as an example of a frequently linked library.
ravi-delia 6y ago
This is quite late, but I thought I'd add my two cents. I use Linux as my only daily driver, and in general I use my distro's package manager. I keep secure by not running random executables and keeping updated, but I'm no infosec engineer and there is a 0% chance that anyone who knew what they were doing couldn't work around everything I have. Flatpak for me is incredibly useful in a narrow use case; other people put in the work to make stuff work without cluttering my damn home directory! Specifically it's helpful for Steam. Why every game on the planet feels the need to fill my home directory with UNHIDDEN directories with spaces in the name (!!!) is absolutely beyond me.
Ericson2314 6y ago
All the things like flatpak annoy me because I have a gut feeling that capsicum is the most incremental change to unix that is both secure and ergonomic, and all these other things sacrifice one or both of those with tons of complexity. Just abandon the epicycles already!
hda111 6y ago
How does snap compare to this: let’s say the Chromium snap? It’s advertised as sandboxed but obviously can download files to your Download directory, it can print PDFs etc, access Webcam of course for video conferences. How is sandboxing supposed to work here?
smoldesu 6y ago
If Flatpak security is this much of a joke, why do people go through the trouble of using it? Flatpaks are outright cumbersome, and bar-none my least favorite way to install anything. Have a local GTK/Qt theme/colorscheme? Gotta manually patch it in. Have a small main drive? You can store maybe three or four Flatpak'd apps. Slow internet connection? Good luck, you'll be here a while. All of it boils down into the outright worst way to distribute software on Linux. I'd rather use Snaps, which should be taken as a violent insult to anyone who's familiar with the medium. Nowadays, if I see that an app is exclusively distributed through Flatpak, I'll compile it from source or find an alternative. The future of software cannot be containerizing anything dangerous or complicated. All it does is add an extra layer of abstraction that makes it harder for the end-user to use your software. All of this seems especially redundant on Linux, where we could take any number of extreme measures to sandbox software. Why did we choose the path of most resistance for the user?
- antimba 6y ago
  > Have a small main drive? You can store maybe three or four Flatpak'd apps. That’s not true. Even the smallest consumer hard drives are big enough to store as many apps as you will want to install. > Slow internet connection? Good luck, you'll be here a while. Flatpak uses OSTree to install and update apps. It is very efficient and generally faster than traditional package managers.
isaiahg 6y ago
Am I alone in that I really don't like using flatpaks or snaps over debs. All the software I've installed from both tends to be buggy and unoptimized. Inkscape from flatpak crashes, Kate can't access system themes, steam barely works and doesn't understand the permission system. It feels so much like these projects are taking software and stuffing it into a box it was never meant to fit. Also I don't really think the problem it fixes really exists. People who use Linux know what they're installing and I don't sandboxing really achieves anything other than getting in the way.
dang 6y ago
https://news.ycombinator.com/item?id=24661126 https://news.ycombinator.com/item?id=24661126
stjohnswarts 6y ago
Hmmm, my computer hasn't blown up and burned my house down nor my bank accounts drained yet...

316 points by URfejk 6y ago

ampdepolymerase 6y ago

What is the security story for Snap and AppImage?

littlestymaar 6y ago
AppImage is a convenience layer which doesn't claim to add any security as it provides no sandboxing whatsoever. And the outdated dependencies in images are likely to exist in the AppImage world too.
- PhilippGille 6y ago
  The AppImage website mentions Firejail as a way to sandbox apps. https://firejail.wordpress.com/documentation-2/appimage-support/ https://firejail.wordpress.com/documentation-2/appimage-supp...

Quickshooter 6y ago

Snaps for services, debs for user apps

batrat 6y ago
you hurt all 9 pacman's out there.
loloquwowndueo 6y ago
Snaps suck for services because they auto-update and either restart daemons without warning or leave the running process in an undefined state.

nodja 6y ago

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

littlestymaar 6y ago
Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?
- mavhc 6y ago
  Passing responsibility of not distributing evil software from the gatekeepers to the user. Ignores half the point of having a distribution that has a package manager, curated software.
  - oblio 6y ago
    So the solution is to have the package manager decide things for every user?
    - diffeomorphism 6y ago
      Yes, the point is to have the package manager set sane defaults for every user. Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all. A much more sane approach would be to enable access to ~/videos and other reasonable places at install time and only ask for additional permission when needed.
      - lokedhs 6y ago
        Flatpak allows this, but requires changers to the application so that it calls the correct API's when requesting files outside of the allowed directories. The article does highlight some actual issues, but the author implies that the solution is to simply not use it at all and go back to the free for all smörgåsbord of access rights that an application installed from the regular repositories have. Personally, I consider Flatpak the best solution available right now time minimise the attack surface for anyone not willing yo go all the way and run Qubes OS. If there is a better alternative I'd be happy to hear it, since I cannot run Qubes one of my machines.

danieldk 6y ago

Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html https://theevilskeleton.frama.io/2021/02/11/response-to-flat...

littlestymaar 6y ago
Interesting part: > It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful. […] They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portals instead of direct home or host filesystem access without losing functionality. Which means that the author still has a point: there are still lots of use cases where the only practical way to use the file-access sandbox is to disable it. Btw, the post you shared is a much more balanced view on Flatpack than the OP, but after having read it I would still consider Flatpack not being ready for what it advertises.
- santoshalper 6y ago
  It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.
  - andrey_utkin 6y ago
    It must not be all or nothing. In firewalls we have rules. In SELinux etc we have rules, and distros package them for you.
    - akvadrako 6y ago
      What kind of rule are you talking about? Flatpak is pretty flexible.

mands 6y ago

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.

ekianjo 6y ago
note that the response partially agrees with the points raised, it looks like a constructive discussion overall.
- nextlevelwizard 6y ago
  It is hard to guess at motives when author is unknown. Or when neither of the CVE links go anywhere. Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages. With ffmpeg I don't know if things like Chromium are actually using the flatpak ffmpeg or if they ship with their own libs.
  - eis 6y ago
    Which is good as one should discuss the merits of the arguments brought forth when discussing the pros and cons of a technology rather than who who said it or what motives they might have. Edit: when I wrote this comment only the first sentence of the parent existed.
  - necovek 6y ago
    You've misunderstood "how Flatpaks work": they are using the same system calls that containers use for containerization but in a different way, look at https://en.wikipedia.org/wiki/Linux_namespaces https://en.wikipedia.org/wiki/Linux_namespaces (Snaps use AppArmor too if that's a more familiar technology). They are not containers in themselves: if you feel this is pedantic, the way namespaces are used can make all the difference (eg. why you should not be running stuff in docker containers as root which can easily be used to get root on the host).

dastx 6y ago

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted). We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.

foobar33333 6y ago
I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it. The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.
- Iolaum 6y ago
  > This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.
  - foobar33333 6y ago
    If the package has host fs access, the sandbox is essentially turned off. A few packages have this because they just don't work without it. The thing is, clickbait bloggers go nuts over this but the state is not any worse than if you had used a .deb The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing. I am certain this is not an intentional misleading feature because Gnome Software is hardly functional and need serious work across the entire program.

hkt 6y ago

Is there a security comparison somewhere of all the new fangled ways of getting up to date desktop software on Linux? snaps etc too? I suppose the real answer may always have been backports on debian distros - which is to say, trusted sources over technical solutions.

eeZah7Ux 6y ago
Spot on.
danieldk 6y ago
which is to say, trusted sources over technical solutions This does not solve the problem where your a PDF reader from a trusted repository happens to have a zero day exploit. When it is exploited, the attacker could have access to all your files, since there are no further limitations unless you bubblewrap or firejail the application yourself. Since sandboxing is one of the goals of Flatpak, the exploit would be limited to the sandbox (if sandboxing was enabled for the PDF reader).
- hkt 6y ago
  It doesn't solve that problem, but it does provide a channel that is likely to receive an update in most distributions. It would be nice to not have to choose between sandboxing and security updates, though.
  - danieldk 6y ago
    I agree, but nobody seems to be really working on (user-friendly) sandboxing of applications distributed through traditional package managers. You can use Firejail or bubblewrap, but they are not exactly user-friendly solutions.

cl3misch 6y ago

All Linux users I know don't use Flatpack/Snap for their sandbox, but much rather for getting the newest version of some UI app (Inkscape) on an older Ubuntu release. I think this shows that a standard release cycle is not appropriate for desktop users.

sjellis 6y ago
Yes, for me the sandboxing is not the immediate benefit. The instant value is providing channels for developers to ship apps to their users without either side having to mandate the OS that the other uses. Right now, even well-funded projects like Visual Studio Code have to pick and choose which Linux distributions and versions that they package for. They don't provide packages to the main repositories for Linux distributions, partly because the release cycles are so wildly different. I don't want Debian stable to ship a completely new base system every few weeks, but the release cycle of my Web browser is a new version every six weeks. In the ideal Flatpak world, I can run Solus or whatever distribution I choose, and the app developers that I rely on can not care about distribution market share, and just target Flatpak runtimes. The challenge is going to be to ensure that Flatpak repositories and the Canonical App Store (the server end of snap) enforce good enough legal and security checks once vendors have started using them.

jart 6y ago

Am I the only one who sees the irony in it being a scandal for free software to fail to adequately restrict freedom? I just can't imagine an iPhone style restrictions model ever gaining momentum in open source. As much of a prize an App Store would be, it's just too at odds with the culture. I think what makes more sense for open source is to have better tools for monitoring what it's doing. The behavior of some of these programs with things like dns is like the hunger games and you can't trust the system to save you with a top-down permissions model when the system itself is the problem.

e_proxus 6y ago
Security and open source philosophy are two completely orthogonal problems. You can a have an open source system that is the most secure, sandboxed implementation there is. Likewise you can have a completely insecure closed source proprietary system. The freedom in open source could be the freedom to structure your system in the most secure way possible for running untrusted applications. It’s just that no one managed to achieve this yet in a satisfying way.
- jart 6y ago
  Not entirely. A few months ago I was reading about a controversy where the Emacs dev team was concerned about the ethics of conducting an online survey. Can you believe that? That's why I like using their software. You just know people who are that extreme philosophically will never in a million years betray you. Don't you think tools like Bochs, QEMU, gVisor, etc. are reasonably satisfying? Security is a hard problem since there's an endless push and shove around its tradeoffs hence why sometimes the best one can afford is monitoring.
psanford 6y ago
I see flatpak and snap as potential solutions to the problem of distributing proprietary software to Linux. Its in that usecase that I really want sandboxing and where the current solutions are lacking. Right now I'm most happy with Firejail for sandboxing proprietary applications. It doesn't solve the packing problem but seems to do the best job at actually limiting what applications can do.

jeppesen-io 6y ago

Shall I plug NixOS?

xvector 6y ago
What is Nix and why is it a better alternative?
- danieldk 6y ago
  There is some overlap and there are a lot of differences. One point of overlap is that Nix makes it easy to install packages that are newer than your os. For example, you could run NixOS 20.09 or Ubuntu 16.04 and have the latest Handbrake or youtube-dl. A large difference it that Flatpak also attempts to sandbox applications, which Nix doesn't (it only sandboxes builds). Though it might be easier to sandbox applications using Nix than traditional package managers, since all dependencies are made explicit.
  - mlinksva 6y ago
    There's a larger amount of overlap with https://spectrum-os.org/ https://spectrum-os.org/ (which builds on Nix). https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland/ https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kv... is also really interesting (and discusses Nix and SpectrumOS) and itself was discussed at https://news.ycombinator.com/item?id=26378854 https://news.ycombinator.com/item?id=26378854
- kaba0 6y ago
  Basically, nix (and guix, which is based on it) is the only package manager that actually solves the dependency hell problem properly. It makes builds reproducible, and basically a package will depend on it’s inputs’ hashes. So you can not only install multiple versions of the same package that is solved by some package managers although in hacky ways, you can install multiple ones that only differ in eg which libc version they link to. In this way, I do think that it is truly revolutionary - but it is a package manager (and NixOS makes basically the OS a big package). Flatpak and snap try to do this as well, in an objectively worse way, but they also provide different features, so they are not in competition. I would rather like to see flatpak and snap employ nix for solving the package management problem and build on top of it. That would actually make the linux solution better than what we have on other OSs.

fguerraz 6y ago

My most recent favourite https://gitlab.gnome.org/GNOME/mutter/-/issues/1606 https://gitlab.gnome.org/GNOME/mutter/-/issues/1606 In this case more of a gnome issue maybe, but the fact that there's no UI feedback from either flatpack or gnome is laughable.

deleted 6y ago

[deleted]

mrweasel 6y ago

Security updates are a huge issue for most “container” formats. Even official image on Docker Hub receive almost zero security updates and most companies seem to have no policy on how to keep container, be it Flatpak, Docker or even LXC containers updated.

antimba 6y ago
> Even official image on Docker Hub receive almost zero security updates Are you talking about the Official Images program? Because if so, this is not true.

cardanome 6y ago

I don't need the security. I don't need automatic updates. As a Linux user, most of my software will be installed with my native package manger and receive the appropriate security updates. Flatpak/Snap/Appimage are just for when the former option is not possible because the software is not available or not in the right version I need. I am making a conscious decision here to seek out that software and can be expected to check for trustworthiness. The Windows world survived decades with running random .exe files from the internet. Some people got hurt but that is fine. Sometimes convenience and productivity can be more important than security. I already have a good sandboxed environment, it is called a web browser. So really for me the only thing I need is some easy way to run an application with just a single click on any Linux system. Appimage works fine for me. All the other features, I don't need them.

LockAndLol 6y ago

"People are trying to do things better, I'll say they aren't and not provide a single option that's better" aka "I'll complain about stuff and not do a single thing to improve it". What a contribution. Typical flame bait website.

cheph 6y ago

> The sandbox is STILL a lie No it is not. If sandboxed means no access to filesystem, sure it would be, but that is not the only definition of sandboxed, that is not the definition of that under which flatpak said they would operate, that is not the definition of sandboxed under which other things operate. If you want them to use a different definition of sandboxed, by all means submit an issue making the case, but you don't even make it here. You just ignore that and then proceed to act as if your definition is the only reasonable one. And if that was the case the very least you can do is find a reference for your definition. Try harder with the FUD.

vntok 6y ago
A single line of code allows any "sandboxed" program to escape from the sandbox. This is not what the word "sandboxed" means for any reasonable definition of "sandboxed".
- cheph 6y ago
  > A single line of code allows any "sandboxed" program to escape from the sandbox. How is that what is happening here?

Shadonototro 6y ago

it doesn't matter what people think both snap/flap user experience is trash linux desktop is doomed to fail people the people who make decisions are clueless and tasteless

preommr 6y ago
linux desktop is never going to take off and died off when all the money moved to the cloud - it's not the 2000s, you can download windows and run it for free because that's not where the money is anymore. For the average user that's not technically oriented, that's going to be their goto solution.
- supernintendo 6y ago
  > linux desktop is never going to take off Who cares? Why is popularity so important to you?
Jonnax 6y ago
What's your idea that would save Linux desktop?
- Shadonototro 6y ago
  less fragmentation, i think Unity 8 could have been the answer, sadly it died way to early..
pjmlp 6y ago
The Linux Desktop has failed already thanks to the endless fragmentation and religious attacks on drivers. Even ChromeOS and Android only package the Linux kernel, while building their own userspace on top. With the Web turning into ChromeOS, and the return of timesharing via the cloud, there is even less reasons to care about the GNU/Linux desktop.
supernintendo 6y ago
> linux desktop is doomed to fail What does this even mean? I’ve been using Arch Linux with KDE as my only desktop OS for years and it’s a wonderful time. If you think Windows is better and prefer to use that, great. I personally prefer Linux and a lot of other people do as well.

krick 6y ago

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, and a number of tools installed via pip or directly downloaded from github. (In fact, you probably use Linux on desktop in order to do all these things, because it makes life easier.) And many users aren't even really aware of the contents of their .bashrc and such. So, is there a security problem with Linux desktop? Yes, absolutely. And it is serious enough to worry for those who are not paranoid security enthusiasts (I mean, even real vulnerabilities aren't truly a concern to many users, but we have to admit there is a problem, when it becomes quite evident, that Linux starts falling behind both MacOS and Windows in this regard). But is flatpak the culprit? No, not really. Linux on desktop in 2021 is just really flawed (at least security-wise).

syockit 6y ago
I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?
- my123 6y ago
  For Windows, there are the Win32 apps that you talk about, which aren't sandboxed. And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.
  - pjmlp 6y ago
    Win32 applications can also be sandboxed, when packaged as MSIX. Windows 10X original roadmap was to merge both sandbox models, and it is also part of Project Reunion goals.
- 6y ago

airhead969 6y ago

And this is why I use Qubes and not Snap, Flatpak, or any of these other cobbled-together emperors-new-clothes app package managers. I knew this would happen from the very beginning but as usual, most software developers just shrug it off.

thecureforzits 6y ago

LOL. It's so easy to troll Linux users. Anonymous websites are a neat way to do it.

pedro2 6y ago

For me Flatpak is akin to Arch’s AUR. As such, rebuilding Flatpak and its various layers should be easily rebuilt from source or equivalent as available as an option (but not the default). That would prevent some of the issues. It would also introduce bugs, but at least you would have the option.

pjfin123 6y ago

I don't have anything against Flatpak but maintain a Snap package and think Snap has made a lot of good design decisions even if it still has rough edges. For a basic application it's pretty easy to package for Snap. A lot of the things that bother Linux power users like polluting their mounted file systems wouldn't matter to regular users. My understanding is they support either pre-declaring permissions or requesting them at run time. https://github.com/argosopentech/argos-translate https://github.com/argosopentech/argos-translate

zajio1am 6y ago

Hot take: Per-application sandboxing is (in general) fundamentally flawed idea, as applications are just tools to manipulate data, while data needs to be protected from unintended manipulations, but such protection should not encumber intended manipulations. What manipulation is intended depends on worflow, not application. Such setup can work on phones due to their limited use cases, but not on desktop. What we need are tools for per-workflow sandboxing. Assign each data to worflow/project (with separate uid), and then execute applications as a part of the project. So applications would have access to data of the project in which they are executed.

higerordermap 6y ago
The world doesn't work like that. 1) application sandboxing isolates different vendor's code, some of which may be security / privacy infringing. 2) There wouldn't be a problem with data sharing in a properly designed sandboxing system. There will be shared filesystem, file chooser / save dialogues so that's not really a problem.

TheMagicHorsey 6y ago

It seems like some of OP's criticisms of Flatpak are not actually criticisms of Flatpak, but rather criticisms of the way Linux works. Perhaps OP would be happier with a capabilities-based operating system (like Google's new Fuschia system). It just seems like these complaints leveled against Flatpak are asking the authors to achieve nearly impossible goals given the complexity of doing sandboxing at the app level in Linux.

vorticalbox 6y ago

> The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed. All of these require access to the users data to actually function. GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media these apps have the same "problem" in snap requiring --classic to allow access to the users files.

andagainagain 6y ago
Question then - does flatpak require an explicit flag when installing them to access those files? Or is it as I assumed just "flatpak install"
- vorticalbox 6y ago
  I actually believe it's set in the flatpack, though I am unsure.

KerrickStaley 6y ago

A small nit about an aside in the article: Is fcitx "the" East Asian IME for Linux? As a speaker of Chinese as a second language, I use IBus (with libpinyin), which is supported out-of-the-box in GNOME and seems to provide a better user experience than fcitx the last time I checked (which was probably 10 years ago).

raffraffraff 6y ago

Semi-related. I wanted to run Amarok 1.4 recently (because I had been having a discussion about how no music player on Linux touches MusicBee, and the last one that had promise, before the developers lost their minds, was Amarok 1.4 - yes I know about Clementine etc but MusicBee still wipes the floor with all of them. This is a digression). Anyway, I spent about an hour attempting to get get it to run on my up-to-date Mint laptop. Now, Amarok 1.4 is 12 years old, so if you want to get it to run, you'll either have to compile it (which means getting your hands on the 12 year old KDE libs), run a 12 year old Linux distribution in a VM, or... Dockerize it. Now you see where the flatpak connection comes in. Step 1: Find an Ubuntu 8.10 ISO and mounted it: sudo mount -o loop ubuntu-8.10-desktop-amd64.iso /mnt/intrepid Step 2: Unqsquash the filesystem: sudo apt-get install -y squashfs-tools sudo unsquashfs -f -d /tmp/unsquashfs /mnt/intrepid/casper/filesystem.squashfs Step 3: Import the tarball into a Docker image: sudo tar -C /tmp/unsquashfs -c . | docker import - ubuntu/intrepid Step 4: Run interactively and install Amarok: docker run -it --entrypoint=/bin/bash ubuntu/intrepid (NOTE: At this point, it was pretty hard to find an apt repo for Ubuntu 8.10 but, amazingly, one or two still exist online. So I edited the apt sources, ran apt-get update && apt-get install -y amarok. I also created a user to run Amarok - one whose uid/gid matched my own user. These commands are left as an exercise for the reader) So I dockerized Amazok 1.4.10 / Ubuntu 8.10. What next? Well, I could have created a Dockerfile that started "FROM ubuntu/intrepid" and repeated all of my manual work I did in the interactive container, but I'm not keeping this thing, so I just did this the hacky way: docker export quirky_mendel -o ubuntu_intrepid_amarok.tar docker import intrepid_amarok.tar amarok:1.4.10 Now I have a docker image called "amarok:1.4.10" which I can share on Docker Hub! Does it work? docker run -it --entrypoint=/usr/bin/amarok --rm --name amarok --net=host --user amarok --privileged -e DISPLAY=:0 -v ${HOME}/.Xauthority:/home/amarok/.Xauthority amarok:1.4.10 IT WORKS! A 12 year old music player running in a docker container on the latest Linux Mint. My alternative to Flatpak / Snap etc. Is it safe? Nope! It's running in an Ubuntu image that wasn't updated since 2008.

superkuh 6y ago

Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically compile or run software written today. That's okay for mega-corps who re-build the entire software universe every time they want to make a change. Or for those who ignore desktop entirely and just "deploy" containers. And that's lead us to today. Linux desktop can't live for more than a few years on it's own. In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. But this doesn't fix the futureshock. It only makes things for desktop users worse.

busterarm 6y ago
I only use Flatpak apps when it's my only option and the only places that seems to be are Electron apps. Discord & Slack, I'm looking at you. I also run a rolling-release distribution...
GekkePrutser 6y ago
Indeed, very good point. Those is why I moved to freebsd for my desktop. Too many corporate interests hijacking Linux right now.
einpoklum 6y ago
> Containers on the desktop are a symptom of a festering underlying disease. Agreed, although we may be in disagreement regarding what the disease is. > Modern Linux development is extremely rapid pace I believe you are over-generalizing, both over different distributions and over different packages within a distribution. > and is 100% targeted at the needs of the corporate entities paying for the development. ... specifically, many distributions are not funded by one, or a few, specific entities, corporate or otherwise. Debian comes to mind. I've never felt its is developed rapidly, or that languages change that quickly. > . Linux desktop can't live for more than a few years on it's own I'm not sure what you mean. > In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. but the rest haven't.

andagainagain 6y ago

One thing that gets me about the sandbox of flatpak is that it doesn't seem to be up to the user. If the developer of the app chooses the permissions, then there isn't a fundamental difference for security from having all permissions anyways. Ideally a user installs the app and they would know, without reading anything else about the app, that the app is separate from their system. If any app you install is NOT separate from the system, then... the sandbox is like making a giant wall but having a door right in the middle of it.

takluyver 6y ago
You're thinking about malicious apps, where the developer would just request all permissions they can. But sandboxing is also about limiting the impact of security issues in apps from honest, well meaning developers who (hopefully) won't request more permissions than they need. E.g. if I make a chat app, and it has a bug that lets someone send you a malicious message and execute code in the app, then a sandbox is a really good thing. The developer also sets the default permissions - in principle, the user can change these before running the app. Of course, not many users will do that, but there are still cases where it can make a difference.

GekkePrutser 6y ago

From the article: > The flatpak runtimes and apps do not get security updates This is exactly what I worry about with things like Flatpak and Snaps (Ubuntu). Instead of having the distro maintainer provide timely security updates, all they have to do now is shrug and point at the external package maintainer. So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. This is clearly not going to work as well. And while sandboxing is a great idea, it can be done using other methods too, like SELinux or AppArmor. Not to mention the wasting of resources by running all those separate versions of each library.. But that's not security-related discussion.

antimba 6y ago
> So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there. [1]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/bootstrap/openssl.bst https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/ma...
- GekkePrutser 6y ago
  Ok bad example then, and I didn't know that, but most libs are not part of the runtime :) I just mentioned openssl as an example of a frequently linked library.

ravi-delia 6y ago

This is quite late, but I thought I'd add my two cents. I use Linux as my only daily driver, and in general I use my distro's package manager. I keep secure by not running random executables and keeping updated, but I'm no infosec engineer and there is a 0% chance that anyone who knew what they were doing couldn't work around everything I have. Flatpak for me is incredibly useful in a narrow use case; other people put in the work to make stuff work without cluttering my damn home directory! Specifically it's helpful for Steam. Why every game on the planet feels the need to fill my home directory with UNHIDDEN directories with spaces in the name (!!!) is absolutely beyond me.

Ericson2314 6y ago

All the things like flatpak annoy me because I have a gut feeling that capsicum is the most incremental change to unix that is both secure and ergonomic, and all these other things sacrifice one or both of those with tons of complexity. Just abandon the epicycles already!

hda111 6y ago

How does snap compare to this: let’s say the Chromium snap? It’s advertised as sandboxed but obviously can download files to your Download directory, it can print PDFs etc, access Webcam of course for video conferences. How is sandboxing supposed to work here?

smoldesu 6y ago

If Flatpak security is this much of a joke, why do people go through the trouble of using it? Flatpaks are outright cumbersome, and bar-none my least favorite way to install anything. Have a local GTK/Qt theme/colorscheme? Gotta manually patch it in. Have a small main drive? You can store maybe three or four Flatpak'd apps. Slow internet connection? Good luck, you'll be here a while. All of it boils down into the outright worst way to distribute software on Linux. I'd rather use Snaps, which should be taken as a violent insult to anyone who's familiar with the medium. Nowadays, if I see that an app is exclusively distributed through Flatpak, I'll compile it from source or find an alternative. The future of software cannot be containerizing anything dangerous or complicated. All it does is add an extra layer of abstraction that makes it harder for the end-user to use your software. All of this seems especially redundant on Linux, where we could take any number of extreme measures to sandbox software. Why did we choose the path of most resistance for the user?

antimba 6y ago
> Have a small main drive? You can store maybe three or four Flatpak'd apps. That’s not true. Even the smallest consumer hard drives are big enough to store as many apps as you will want to install. > Slow internet connection? Good luck, you'll be here a while. Flatpak uses OSTree to install and update apps. It is very efficient and generally faster than traditional package managers.

isaiahg 6y ago

Am I alone in that I really don't like using flatpaks or snaps over debs. All the software I've installed from both tends to be buggy and unoptimized. Inkscape from flatpak crashes, Kate can't access system themes, steam barely works and doesn't understand the permission system. It feels so much like these projects are taking software and stuffing it into a box it was never meant to fit. Also I don't really think the problem it fixes really exists. People who use Linux know what they're installing and I don't sandboxing really achieves anything other than getting in the way.

dang 6y ago

https://news.ycombinator.com/item?id=24661126 https://news.ycombinator.com/item?id=24661126

stjohnswarts 6y ago

Hmmm, my computer hasn't blown up and burned my house down nor my bank accounts drained yet...