I see that it can be slower because of having all the dependencies included with the flatpak itself instead of relying solely on whats installed on the system. I read that this means it isolates or sandboxes itself from the rest of the system.

Does this not mean that it can’t infect the rest of the system even if it had malware?

I have seen people say that it isnt good for security because sometimes they force you to use a specific version of certain dependencies that often times are outdated but I’m wondering why that would matter if it was truly sandboxed and isolated.

Do they mean that installing flatpak itself is a security risk or that also specific flatpaks can be security risks themselves?

  • cmgvd3lw@discuss.tchncs.de
    link
    fedilink
    arrow-up
    19
    ·
    15 hours ago

    Go to flathub and check the permission of the application that you want to install. Normally they won’t have access to root directory, but could access your home dir. If they had any malicious intent, they could mess with your personal files.
    I think there is another application that can restrict the permission scope on flathub itself.

    • Ashley@lemmy.ca
      link
      fedilink
      arrow-up
      10
      ·
      15 hours ago

      Also flatpaks are moving away from file system permissions towards portals. Though currently I wouldn’t see flatpak as much of a security measure.

    • Cyborganism@lemmy.ca
      link
      fedilink
      arrow-up
      5
      ·
      15 hours ago

      Yeah but OP has a point regarding the libraries with known vulnerabilities. What if one of them gets exploited that allows remote malicious code execution and gives root access? I dunno how far the sandboxing goes in that regard.

      • Max-P@lemmy.max-p.me
        link
        fedilink
        arrow-up
        8
        ·
        15 hours ago

        The sandboxing is almost always better because it’s an extra layer.

        Even if you gain root inside the container, you’re not necessarily even root on the host. So you have to exploit some software that has a known vulnerable library, trigger that in that single application that uses this particular library version, root or escape the container, and then root the host too.

        The most likely outcome is it messes up your home folder and anything your user have access to, but more likely less.

        Also, something with a known vulnerability doesn’t mean it’s triggerable. If you use say, a zip library and only use it to decompress your own assets, then it doesn’t matter what bugs it has, it will only ever decompress that one known good zip file. It’s only a problem if untrusted files gets involved that you can trick the user in causing them to be opened and trigger the exploit.

        It’s not ideal to have outdated dependencies, but the sandboxing helps a lot, and the fact only a few apps have known vulnerable libraries further reduces the attack surface. You start having to chain a lot of exploits to do anything meaningful, and at that point you target those kind of efforts to bigger more valuable targets.

        • Cyborganism@lemmy.ca
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          7 hours ago

          The sandboxing isn’t as much as, say, Docker containers. So I think access to memory and devices is still possible and can eventually get you access to the whole system. I would think.

          And this isn’t limited to flatpaks but I would assume Snaps as well, which some software is now delivered in that format by Canonical, even for server software.

          That’s interesting. I’ll have to look deeper into that