9 ms·

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html https://theevilskeleton.frama.io/2021/02/

by 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).
- foobar33333 6y ago
  The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets exposed as well as less permissions being given to packages.
  - eeZah7Ux 6y ago
    > If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo True, and the same is true for flatpak given that the author of the package controls the sandboxing. The only solution is to have 1 or 2 trusted packagers to review the package, including its code - which is what some Linux distributions do. Furthermore, Debian does a long release freeze for the stable release and a lot of users test it. A malicious package might well be spotted. Contrast it with the very lightweight vetting that is done by others.
    - foobar33333 6y ago
      Flathub actually does review submissions reasonably well. You have to give a justification for each permission you request and why it couldn't be done in any other way.
  - necovek 6y ago
    The thing is that messaging is the important bit here. If I have Debian apt archives in my sources.list, I understand the risks, just like a pure Windows user does: other than bugs, you might be affected if someone hacks Debian/Microsoft and that's it (or, of course, someone internal to them decides to do it). Flatpaks/snaps are designed to be built by less-trusted parties and promise things they know they can't deliver on. Now I am suddenly asked to trust these external developers that they will be as adamant with security fixes, be non-malicious, etc. And flatpak/snap are trying to convince me how that's a non-issue "because sandboxing". Sure, we here understand the underlying technologies so we can make our own educated guesses, but majority of the people who this is aimed at don't. Since you also mentioned "add a new repo", there are some repos you can trust even if they are not the official ones. PPAs on Launchpad build from source packages, so you can always get the source first ("apt-get source package" after adding the repo). If someone is just bundling binaries and the build is a no-op, you can drop the repo right away. Sure, it requires some effort and you won't be checking every repo, but for sufficiently popular repos, somebody would be doing that. It'd be ideal if apr grew support for limiting packages that can come out of a repo, so you'd have to whitelist when something new pops up ("hey, this repo has now introduced libc version X, and your libc is coming from repo main: do you want to allow upgrades from non-main repo to libc? [only once] [yes] [no]").
- mands 6y ago
  Agreed, as far as constructive discussion can be had with a post from a domain called flatkill.org :)
kelnos 6y ago
I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many. I haven't used Flatpak (or Snap) before, but my impression of the technology was that it isolates apps and strongly sandboxes things so if you accidentally run something malicious, you're covered. But that doesn't seem to be the case, really. I get that this is a hard problem, and some things aren't even possible to do on X11, but then don't leave people with the belief that you can do all these things. The response also says: > Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape. That is just an awful approach to security. You need to deny by default and selectively allow, not allow by default and selectively deny. Applications do not need explicit permissions to get r/w access to blocked directories; they can simply append to ~/.bashrc or whatever, and bam, they have "permission". I'd heard some bad things about Snap, but looks like I'll be staying away from Flatpak as well.
- orf 6y ago
  > Well, ok, sure, that's definitely not "almost all", but that's still way too many. And a couple of sentences after it goes on to explain that it’s not too many because most of those 23 need those permissions.
- gspr 6y ago
  It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.
oedmarap 6y ago
Great article, thank you for sharing. I use Flatpak extensively and I fully agree with you and the author of the response that there is a need to balance practicality vs. idealism when it comes to (fully auditable) FlatPak apps, as well as FlatHub's overall approach and continual work within the desktop Linux ecosystem. What's more, the fact that an entire domain was devoted to what could have been a blog post gives credence to the responder's notion that this is FUD which, while valid for discussion, is most certainly not beneficial to the FOSS community writ large. Either way, from the article you linked TIL about Flatseal[0] so I'll be taking that for a spin! [0] https://github.com/tchx84/Flatseal https://github.com/tchx84/Flatseal
Blikkentrekker 6y ago
I find your takeway that it is f.u.d. from this response quaint. To sum up the issues: - We agree that write access to the entire home directory compromises any and all security, but we are aware of the problem and trying to fix it. - We checked the claim of “Many of the popular flatpack applications still have access to the entire home directory,” and conclude that 23 of the 50 most popular ones do. - We partially disagree that the “sandboxed” icon is misleading, because it does limit some things, even though we as per issue one agree that access to the full home directory gives malware carte blanche. - We agree on the point that the outdated example library with a vulnerability used is true as stated. - We agree with the issue, but we have a tool built that mitigates it by altering developers. I hardly would say that this rebuttal amounts to showing “f.u.d.”; — it alleges no technical falsehood in the article, but at some points simply disagrees that it is as much of a problem as the article claims it is, not numerically in terms of facts, but simply disagreeing on whether full write access to the home directory is truly such a big issue as the original article makes it out to be.
- antimba 6y ago
  There are several technical falsehoods on https://flatkill.org/2020/ https://flatkill.org/2020/. For example, this one: > Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example: > Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)? This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add. And here’s another falsehood: > So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.
zokula 6y ago
Systemd and Wayland being cancer is not nonsense.

by mands 6y ago

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).
foobar33333 6y ago
The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets exposed as well as less permissions being given to packages.
- eeZah7Ux 6y ago
  > If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo True, and the same is true for flatpak given that the author of the package controls the sandboxing. The only solution is to have 1 or 2 trusted packagers to review the package, including its code - which is what some Linux distributions do. Furthermore, Debian does a long release freeze for the stable release and a lot of users test it. A malicious package might well be spotted. Contrast it with the very lightweight vetting that is done by others.
  - foobar33333 6y ago
    Flathub actually does review submissions reasonably well. You have to give a justification for each permission you request and why it couldn't be done in any other way.
- necovek 6y ago
  The thing is that messaging is the important bit here. If I have Debian apt archives in my sources.list, I understand the risks, just like a pure Windows user does: other than bugs, you might be affected if someone hacks Debian/Microsoft and that's it (or, of course, someone internal to them decides to do it). Flatpaks/snaps are designed to be built by less-trusted parties and promise things they know they can't deliver on. Now I am suddenly asked to trust these external developers that they will be as adamant with security fixes, be non-malicious, etc. And flatpak/snap are trying to convince me how that's a non-issue "because sandboxing". Sure, we here understand the underlying technologies so we can make our own educated guesses, but majority of the people who this is aimed at don't. Since you also mentioned "add a new repo", there are some repos you can trust even if they are not the official ones. PPAs on Launchpad build from source packages, so you can always get the source first ("apt-get source package" after adding the repo). If someone is just bundling binaries and the build is a no-op, you can drop the repo right away. Sure, it requires some effort and you won't be checking every repo, but for sufficiently popular repos, somebody would be doing that. It'd be ideal if apr grew support for limiting packages that can come out of a repo, so you'd have to whitelist when something new pops up ("hey, this repo has now introduced libc version X, and your libc is coming from repo main: do you want to allow upgrades from non-main repo to libc? [only once] [yes] [no]").
mands 6y ago
Agreed, as far as constructive discussion can be had with a post from a domain called flatkill.org :)

kelnos 6y ago

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many. I haven't used Flatpak (or Snap) before, but my impression of the technology was that it isolates apps and strongly sandboxes things so if you accidentally run something malicious, you're covered. But that doesn't seem to be the case, really. I get that this is a hard problem, and some things aren't even possible to do on X11, but then don't leave people with the belief that you can do all these things. The response also says: > Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape. That is just an awful approach to security. You need to deny by default and selectively allow, not allow by default and selectively deny. Applications do not need explicit permissions to get r/w access to blocked directories; they can simply append to ~/.bashrc or whatever, and bam, they have "permission". I'd heard some bad things about Snap, but looks like I'll be staying away from Flatpak as well.

orf 6y ago
> Well, ok, sure, that's definitely not "almost all", but that's still way too many. And a couple of sentences after it goes on to explain that it’s not too many because most of those 23 need those permissions.
gspr 6y ago
It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

oedmarap 6y ago

Great article, thank you for sharing. I use Flatpak extensively and I fully agree with you and the author of the response that there is a need to balance practicality vs. idealism when it comes to (fully auditable) FlatPak apps, as well as FlatHub's overall approach and continual work within the desktop Linux ecosystem. What's more, the fact that an entire domain was devoted to what could have been a blog post gives credence to the responder's notion that this is FUD which, while valid for discussion, is most certainly not beneficial to the FOSS community writ large. Either way, from the article you linked TIL about Flatseal[0] so I'll be taking that for a spin! [0] https://github.com/tchx84/Flatseal https://github.com/tchx84/Flatseal

Blikkentrekker 6y ago

I find your takeway that it is f.u.d. from this response quaint. To sum up the issues: - We agree that write access to the entire home directory compromises any and all security, but we are aware of the problem and trying to fix it. - We checked the claim of “Many of the popular flatpack applications still have access to the entire home directory,” and conclude that 23 of the 50 most popular ones do. - We partially disagree that the “sandboxed” icon is misleading, because it does limit some things, even though we as per issue one agree that access to the full home directory gives malware carte blanche. - We agree on the point that the outdated example library with a vulnerability used is true as stated. - We agree with the issue, but we have a tool built that mitigates it by altering developers. I hardly would say that this rebuttal amounts to showing “f.u.d.”; — it alleges no technical falsehood in the article, but at some points simply disagrees that it is as much of a problem as the article claims it is, not numerically in terms of facts, but simply disagreeing on whether full write access to the home directory is truly such a big issue as the original article makes it out to be.

antimba 6y ago
There are several technical falsehoods on https://flatkill.org/2020/ https://flatkill.org/2020/. For example, this one: > Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example: > Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)? This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add. And here’s another falsehood: > So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.

zokula 6y ago

Systemd and Wayland being cancer is not nonsense.