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?

  • 2xsaiko
    link
    fedilink
    arrow-up
    3
    ·
    1 hour ago

    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.

    No. Packing its own libraries wouldn’t make it slower. If anything it would be the extra access checks added by the sandbox (which is optional FWIW, apps don’t have to use it). I haven’t ever used Flatpak but I would assume the sandbox impact is minimal if at all noticeable.

  • UnfortunateShort@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    3 hours ago

    In short: No. It’s getting better, but Flatpak is by no means secure. Think of it as a Windows .exe or .msi with some (not that hardened) rights management.

    In addition, Flatpaks afe often community made and not even “signed” (which is not really a thing in Flatpak to begin with (yet) ((afaik))).

    Something really secure would be a container, something really, really secure would be a VM, something really, really, really secure would be a separate machine. Flatpak is less secure than the least secure thing in this enumeration.

  • BananaTrifleViolin@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    9 hours ago

    Flatpak is supposed to be a sandbox, so if there is a vulnerable dependency then in theory any attack would be limited to the sandbox.

    However, it depends on the software - some Flatpak need quite low level access to use, and in that case an attack or mlaware could get into the main system. And unfortunately Flatpak itself has vulnerabilities which cna negate the whole idea of a sandbox.

    Flatpaks should be using up to date secure dependencies, but the reality is many do not. I would not rely on Flatpak for security. Even fully up to date Flatpaks can be insecure, and Flatpak itself have vulnerabilities that have needed fixing. And for many Flatpaks it’s not even clear who is maintaining them.

    Flatpaks are useful for deploying software that’s just not available in your distros repos. But when deploying any software outside your repos - including App Image, build from source or 3rd party repos - you are opening your system up to security vulnerabilities. That’s the nature of installing 3rd party software. Flatpak offers some reassurance compared to some methods but it’s far from perfect.

    If security is your prime concern, then Virtual Machines may be more secure route to sandboxing software (if done properly). Building from source would be the other option, as it means you take ont he responsibility for security by using the latest code including for dependencies. But there is no perfect option, it’s always about balancing risk vs convenience.

    It’s also worth noting that software repos are also not perfect. But good distros invest a lot of time and effort in keeping them as up to date and secure as possible, usually via the hard work of volunteers.

    • mx_smith@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      8 hours ago

      I wish I saw this post yesterday before I installed VSCode from flathub, trying to get the terminal to see the same file system as my other shells. I got it fixed and learned a lot about flatpak.

  • GolfNovemberUniform@lemmy.ml
    link
    fedilink
    arrow-up
    10
    arrow-down
    2
    ·
    11 hours ago

    There are vulnerabilities found in Flatpak’s sandboxing all the time so it’s pretty much broken. The opening speed on HDD systems is really really bad too. That’s why I only use Flatpak to install software that’s not available in my distro’s repos. Though I use Arch (btw) so distro packages being old isn’t an issue for me.

    • someonesmall@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      21 minutes ago

      It’s still better than no sandbox at all, isn’t it? And who installs their OS on an HDD in 2024?

  • cmgvd3lw
    link
    fedilink
    arrow-up
    19
    ·
    14 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
      ·
      14 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
      ·
      14 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
        9
        ·
        13 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
          6 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

  • Xylight@lemdro.id
    link
    fedilink
    English
    arrow-up
    7
    ·
    14 hours ago

    It’s not securely sandboxed like a Qube, but apps can have their permission to access files and such restricted. Malware can escape the sandbox, or apps may come with very permissive permissions.