7 ms·

> A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly. I don't like the snarky tone of the a

> A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly. I don't like the snarky tone of the article, but I really thing you're being naive here. Let's examine the facts: - Flatpak's intent is clear and stated first in in their homepage [1]: "Flatpak is a next-generation technology for building and distributing desktop applications on Linux" - Red Hat is the company other companies hire to manage their linux systems. - In the flatpak homepage there's a huge quote stating "The Fedora Workstation team are very excited about Flatpak and the prospects it brings for making the Linux desktop easier to develop for. We plan to continue supporting this effort going forward." - The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it. I don't think this is stupidity. This is flat out lying to try and get mindshare.

TheDong 8y ago
> The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it They are using those features. flatpak has network namespaces for applications that don't need access to the network and bindmounts for applications that use very limited parts of the filesystem. Sure, in reality many desktop apps have more far-reaching permissions, but all they're saying is that flatpak can make use of those features in some cases. > This is flat out lying to try and get mindshare Usually that's just called marketing. I don't think any of the above statements are actually lies in any way though. Can you point to what's actually a lie, or what lie is implied in your mind?
- jessaustin 8y ago
  The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.
  - viraptor 8y ago
    The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided. It's like standard Linux permissions. If you install an app which creates its directories with mode 0777, or install a package which has a suid binary, you don't complain that Linux offers no file access control. That's the author's or packager's fault.
    - yzmtf2008 8y ago
      “Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.
      - untog 8y ago
        It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.
        yzmtf2008 8y ago
        macOS does this via the open dialog — opening a directory gives an application full access to that directory
        m45t3r 8y ago
        And you can have the same issue the author said in the article by requesting access to home directory and running the exactly the same command as the author wrote.
        int_19h 8y ago
        You'd need to open your entire home dir for that. In VSCode, you normally open the specific directory that contains the source for one particular project you're working on, so in that model, it would only be granted permission to that directory.
gbraad 8y ago
Fedora and Red Hat are not the same thing. Sure, there is a relation between the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion in RHEL. I just wonder why the author of this page does not disclose his name... And even hides this from the whois info. This could have been written by a person with a grudge for all I am concerned. Sure, improvements might be needed, but haa the author tried to get this happen in a different way, like a discussion? Creating a webpage and scream fire is not the best approach in my opinion. The issue raised about security updates for packaged apps is the same as for container images and packages like .deb or .rpm in general. Generating a runtime is a possible solution? Something like an automated way to regenrate packages is needed, like flathub?!?
- dpwm 8y ago
  > I just wonder why the author of this page does not disclose his name... > And even hides this from the whois info. The registrant country is listed as France and the registrar is OVH. They are simply adhering to the GDPR. I have domains that have been like this since May, even though I would be quite happy to have everything public. > This could have been written by a person with a grudge for all I am concerned. Your comment could have been written by somebody with a grudge against the person you are claiming could have had a grudge for all I am concerned. A vested interest can make a difference, but I don't really see how any of the points are hard to verify. Does this being written by a person with a grudge really negate the points made? - Flatpak is claiming to be secure - Flatpak is sandboxing apps with full access to your home directory. (What is the worst thing that an app can do? Nuke your home directory or run malicious software. The sandboxing here does little to mitigate this.) - Apps are not being updated as quickly as their distribution repository counterparts. - At some point in its past, a (presumably) privileged component with permissions to setuid did not check that it wasn't blindly copying setuid. It seems to me that this is more about easy delivery of software with a security claim that is arguably pretty weak at the moment against likely attack vectors. I can't see that changing without first thinking of what you're actually sandboxing for. There are already software delivery systems, such as 0install and appimage, that do not make claims about being sandboxed and yet provide a similar (or greater in the setuid case) level of security for the main threats. I find it hard to understand who the project is for. If you're a developer on your own machine then using your distro's package manager is probably more secure. If you're a sysadmin, letting users use flatpak serves only to increase the attack surface for privilege escalation.
vanderZwan 8y ago
I'm going to stay a on the meta-discussions level for a bit (all other points in this debate have already been made anyway). Hanlon's Razor is about assuming intent, about railroading others into perceived roles. You bring up interesting points, but they were not part of the article we are responding to. The conclusion was supposed to follow from the earlier arguments given. Within that context there is a big assumption being made. So what am I being naive about, exactly? Note that I have merely called out the assumptions made by others. I have not stated anything about Red Hat's intentions myself, so if I'm being perceived as naive about that, it would be making another assumption. EDIT: I suppose the "mistake" wording does imply good faith behavior. But there too: bad faith should be looked out for, tested for, but not presumed about others.
ricardobeat 8y ago
The sandbox is there for portability. I don't see a promise of being _more secure_ than other app distribution channels on linux anywhere. Though the packaging & sandboxing model certainly opens a path for improvements in the area. Is it any less safe than installing something via aptitude or Ubuntu's app store?
- Shorel 8y ago
  The alternative if using Ubuntu is called Snap. It has a sandbox and it is better implemented, at the very least the part about reading and writing in home dir.
  - deleted 8y ago
    [deleted]
  - MayeulC 8y ago
    As far as I was told, snap sandboxing only works with a specially-patched (and apparmor-enabled) kernel [1], though I am not sure what the current status is. I would like to know what's better implemented in snap, it seems this is simply a case of most applications requesting a r/w permission in the home directory. It might get complicated sandboxing vs code without that, don't you think? Or at least lead to a subpar user experience. I am hopeful it will improve, though. Sandboxing needs to become the default. [1]: https://web.archive.org/web/20170615042616/https://github.com/snapcore/snapd/wiki/Distributions https://web.archive.org/web/20170615042616/https://github.co... Edit: Similar echo here https://news.ycombinator.com/item?id=18180877 https://news.ycombinator.com/item?id=18180877

TheDong 8y ago

> The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it They are using those features. flatpak has network namespaces for applications that don't need access to the network and bindmounts for applications that use very limited parts of the filesystem. Sure, in reality many desktop apps have more far-reaching permissions, but all they're saying is that flatpak can make use of those features in some cases. > This is flat out lying to try and get mindshare Usually that's just called marketing. I don't think any of the above statements are actually lies in any way though. Can you point to what's actually a lie, or what lie is implied in your mind?

jessaustin 8y ago
The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.
- viraptor 8y ago
  The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided. It's like standard Linux permissions. If you install an app which creates its directories with mode 0777, or install a package which has a suid binary, you don't complain that Linux offers no file access control. That's the author's or packager's fault.
  - yzmtf2008 8y ago
    “Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.
    - untog 8y ago
      It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.
      - yzmtf2008 8y ago
        macOS does this via the open dialog — opening a directory gives an application full access to that directory
        m45t3r 8y ago
        And you can have the same issue the author said in the article by requesting access to home directory and running the exactly the same command as the author wrote.
        int_19h 8y ago
        You'd need to open your entire home dir for that. In VSCode, you normally open the specific directory that contains the source for one particular project you're working on, so in that model, it would only be granted permission to that directory.

gbraad 8y ago

Fedora and Red Hat are not the same thing. Sure, there is a relation between the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion in RHEL. I just wonder why the author of this page does not disclose his name... And even hides this from the whois info. This could have been written by a person with a grudge for all I am concerned. Sure, improvements might be needed, but haa the author tried to get this happen in a different way, like a discussion? Creating a webpage and scream fire is not the best approach in my opinion. The issue raised about security updates for packaged apps is the same as for container images and packages like .deb or .rpm in general. Generating a runtime is a possible solution? Something like an automated way to regenrate packages is needed, like flathub?!?

dpwm 8y ago
> I just wonder why the author of this page does not disclose his name... > And even hides this from the whois info. The registrant country is listed as France and the registrar is OVH. They are simply adhering to the GDPR. I have domains that have been like this since May, even though I would be quite happy to have everything public. > This could have been written by a person with a grudge for all I am concerned. Your comment could have been written by somebody with a grudge against the person you are claiming could have had a grudge for all I am concerned. A vested interest can make a difference, but I don't really see how any of the points are hard to verify. Does this being written by a person with a grudge really negate the points made? - Flatpak is claiming to be secure - Flatpak is sandboxing apps with full access to your home directory. (What is the worst thing that an app can do? Nuke your home directory or run malicious software. The sandboxing here does little to mitigate this.) - Apps are not being updated as quickly as their distribution repository counterparts. - At some point in its past, a (presumably) privileged component with permissions to setuid did not check that it wasn't blindly copying setuid. It seems to me that this is more about easy delivery of software with a security claim that is arguably pretty weak at the moment against likely attack vectors. I can't see that changing without first thinking of what you're actually sandboxing for. There are already software delivery systems, such as 0install and appimage, that do not make claims about being sandboxed and yet provide a similar (or greater in the setuid case) level of security for the main threats. I find it hard to understand who the project is for. If you're a developer on your own machine then using your distro's package manager is probably more secure. If you're a sysadmin, letting users use flatpak serves only to increase the attack surface for privilege escalation.

vanderZwan 8y ago

I'm going to stay a on the meta-discussions level for a bit (all other points in this debate have already been made anyway). Hanlon's Razor is about assuming intent, about railroading others into perceived roles. You bring up interesting points, but they were not part of the article we are responding to. The conclusion was supposed to follow from the earlier arguments given. Within that context there is a big assumption being made. So what am I being naive about, exactly? Note that I have merely called out the assumptions made by others. I have not stated anything about Red Hat's intentions myself, so if I'm being perceived as naive about that, it would be making another assumption. EDIT: I suppose the "mistake" wording does imply good faith behavior. But there too: bad faith should be looked out for, tested for, but not presumed about others.

ricardobeat 8y ago

The sandbox is there for portability. I don't see a promise of being _more secure_ than other app distribution channels on linux anywhere. Though the packaging & sandboxing model certainly opens a path for improvements in the area. Is it any less safe than installing something via aptitude or Ubuntu's app store?

Shorel 8y ago
The alternative if using Ubuntu is called Snap. It has a sandbox and it is better implemented, at the very least the part about reading and writing in home dir.
- deleted 8y ago
  [deleted]
- MayeulC 8y ago
  As far as I was told, snap sandboxing only works with a specially-patched (and apparmor-enabled) kernel [1], though I am not sure what the current status is. I would like to know what's better implemented in snap, it seems this is simply a case of most applications requesting a r/w permission in the home directory. It might get complicated sandboxing vs code without that, don't you think? Or at least lead to a subpar user experience. I am hopeful it will improve, though. Sandboxing needs to become the default. [1]: https://web.archive.org/web/20170615042616/https://github.com/snapcore/snapd/wiki/Distributions https://web.archive.org/web/20170615042616/https://github.co... Edit: Similar echo here https://news.ycombinator.com/item?id=18180877 https://news.ycombinator.com/item?id=18180877