• AnUnusualRelic@lemmy.world
    2553·
    1 year ago

    It’s not fully sandboxed if it can write to my screen! That filthy app, writing stuff all over the place!

    • tony@lemmy.hoyle.me.uk
      17712·
      1 year ago

      Or actually do anything useful? No network, no filesystem… it’s a hello world app isn’t it…

      • cheer@lemmy.world
        123·
        1 year ago

        No filesystem access for a flatpak app just means it cant read host system files on its own, without user permission. You can still give it files or directories of files through the file explorer for the app to work with, just that it’s much safer since it can only otherwise view files in its sandbox.

          • null@slrpnk.net
            27·
            1 year ago

            As if sandboxes are some brand new concept…

            Of course people want them for some use-cases. No one here is saying that every application in the world should be restricted that way, grandpa.

            • kautau@lemmy.world
              7·
              1 year ago

              Yeah things like selinux and apparmor have been around for a long time, sandboxing is just an evolution of that

            • grue@lemmy.worldEnglish
              5·
              1 year ago

              No one here is saying that every application in the world should be restricted that way, grandpa.

              Maybe not here in this thread, but aren’t there some folks who want flatpak/snap/appimage to basically replace traditional package managers?

              • null@slrpnk.net
                3·
                1 year ago

                Doesn’t make it a prevailing attitude worthy of whatever nonsense that other guy is spouting.

              • Chewy
                2·
                1 year ago

                […] aren’t there some folks who want flatpak/snap/appimage to basically replace traditional package managers?

                There might be people who think that, but that isn’t realistic. Flatpak is a package manager for user facing apps, mostly gui apps.

                The core system apps will still be installed by a system package manager. I.e rpm-ostree on immutable Fedora or transactional-update/zypper on OpenSUSE MicroOS.

                Snap can do system apps and user facing apps and fully snap-based Ubuntu might come in the future.

                But this won’t force people to use them. Traditional package managers will keep existing for system apps and maintainers will proabably keep their gui packages in the repos.

      • IverCoder@lemm.eeOPEnglish
        24·
        1 year ago

        There’s Obfuscate, an image redactor, and Metadata Cleaner which is self-descriptive. Both works properly without any filesystem access at all, because they use the file picker portal to ask the user for the files to be processed.

    • Empricorn@feddit.nlEnglish
      415·
      1 year ago

      Oh come on, what modern program actually needs to communicate or access the file system?

    • IverCoder@lemm.eeOPEnglish
      24·
      1 year ago

      The app can then declare the network permission and it will still be marked as safe.

  • Spectacle8011@lemmy.comfysnug.space
    621·
    1 year ago

    What really needs to happen:

    Flatpak packages should ask for every permission they need, and the user needs to approve every one of them.

    Right now, we have this weird in-between state where some flatpak packages ship with limited permissions (like Bottles). That’s because every permission the package asks for is immediately granted. The user doesn’t get a chance to refuse these requests. This current model serves to make life more difficult for non-malicious flatpak packagers while failing to protect users from malicious packages.

    Also, GNOME needs a Flatpak permissions center like KDE. You shouldn’t need to install a third party program to manage permissions.

    • JoYo 🇺🇸@lemmy.mlEnglish
      244·
      1 year ago

      it’s weird that android and ios already provide this but THE container standard doesn’t

    • miss_brainfart@lemmy.ml
      15·
      1 year ago

      Absolutely, permissions should be disabled by default, and only when the app needs to do something that requires a certain permission should it ask for it.

      Maybe even do something like Android, where permissions automatically get revoked if you don’t use an app for a certain time. I love that feature.

      • oldfart@lemm.ee
        2·
        1 year ago

        It’s the first time I hear someone praise Android messing with user’s settings. Care to elaborate why you like it?

        • miss_brainfart@lemmy.ml
          4·
          1 year ago

          There is very little reason any app should keep its permissions if you never actually use it, is there?

          Especially when most people use apps that phone home every last piece of data they give them access to.

          • oldfart@lemm.ee
            3·
            1 year ago

            I don’t agree but I see your point, that would certainly be useful to some people. Thank you for explaining.

            • miss_brainfart@lemmy.ml
              1·
              1 year ago

              I think it’s enabled by default, but you can also just disable it for specific apps.

              But if you leave it enabled and permissions get revoked after a while, you’ll get a notification telling you about it. I think that’s fair.

              There’s always going to be a debate on whether something like this should be opt-in or opt-out, but for the purpose of privacy and data security, it makes sense to be on by default, I reckon.

    • FOSS Is Fun@lemmy.mlEnglish
      8·
      1 year ago

      I’ve tried to combat this a bit with a global Flatpak override that takes unnecessarily broad permissions away by default, like filesystem=home, but apps could easily circumvent it by requesting permissions for specific subdirectories. This cat-and-mouse game could be fixed by allowing a recursive override, such as nofilesystem=home/*.

      But even then, there is still the issue with D-Bus access, which is even more difficult to control …

      I think it is sad that Flatpak finally provides the tool to restrict desktop apps in the same way that mobile apps have been restricted for a decade, but the implementation chooses to be insecure by default and only provides limited options to make it secure by default.

      • TeryVeneno@lemmy.ml
        1·
        1 year ago

        I think the main reason why the implementation is insecure by default is simply because when it started most applications did not use portals and many portals we have today did not exist. You had to poke holes in the sandbox to make anything work cause all applications expected to run unconstrained. In the future as more apps become flatpak aware this should stop being an issue.

      • Spectacle8011@lemmy.comfysnug.space
        2·
        1 year ago

        I don’t doubt it, but this is a good place to start.

        This claim has interesting phrasing:

        Adding X11 sandboxing via a nested X11 server, such as Xpra, would not be difficult, but Flatpak developers refuse to acknowledge this and continue to claim, “X11 is impossible to secure”.

        If you look at the GNOME post, you’ll see they haven’t argued against including a nested X server at all:

        Now that the basics are working it’s time to start looking at how to create a real sandbox. This is going to require a lot of changes to the Linux stack. For instance, we have to use Wayland instead of X11, because X11 is impossible to secure.

        I’m not saying they haven’t refused to acknowledge this elsewhere, but it’s strange to point to this blog post which acknowledges that the sandbox is very much a work-in-progress and agrees with Madaidan that X11 is hard to secure.

        Does Xpra provide better sandboxing than XWayland? If not, I think the Flatpak developer’s solution to this is: just use Wayland. And obviously, there’s plenty of room to improve with the permissions Flatpak does offer.

        I did some searching on the Flatpak Github for issues and found that you can actually use Xpra with Flatpak, and the answer is “just use Wayland”:

        This is also concerning:

        As odd as this may sound, you should not enable (blind) unattended updates of Flatpak packages. If you or a Flatpak frontend (app store) simply executes flatpak update -y, Flatpaks will be automatically granted any new permissions declared upstream without notifying you. Using automatic update with GNOME Software is fine, as it does not automatically update Flatpaks with permission changes and notifies the user instead.

        Source: https://privsec.dev/posts/linux/desktop-linux-hardening/#flatpak

        It’s great that GNOME Software notifies you when permissions change! I don’t use Flatpak enough to know, but I hope flatpak update notifies you too if you don’t use the -y option.

  • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.one
    351·
    1 year ago

    This kind of thing could work for a few apps, say a color picker utility or a QR code generator etc.

    Looking at the docs, it isn’t clear if apps can write to their own namespace (instead of writing to user folders directly), but if they can, we could expand the scope to games like supertuxkart, 2048 etc, which would then be able to save user milestones and progress in their own area - a bit like how Android apps do it

    https://docs.flatpak.org/en/latest/sandbox-permissions.html

    It’s a great start IMO, although admittedly there is still work to do. Flatpak atm bridges the gap with allowing new apps, requiring new libs, to run on older stable/LTS distros

    • themoonisacheese@sh.itjust.works
      211·
      1 year ago

      Yes, they can. There are app-specific folders in .local that flatpaks can read and write to specifically for this purpose, and also the file picking dialog may give access to the one specific file you picked.

      Android IMO has great usability in exposing a database to apps, which means they aren’t required to ship their own database engine.

      • andruid@lemmy.ml
        2·
        1 year ago

        Get a database, data que and service mesh and we can have an advanced k8s style platform.

    • IverCoder@lemm.eeOPEnglish
      27·
      1 year ago

      With a bit of modifying code to use the color picker and maybe rearranging the workflow to adapt to the new system, apps as advanced as DaVinci Resolve and LibreOffice can have permissions as restrictive as this (the network permission would of course may be needed but it would still be marked as Safe by Flathub).

      You can use the file picker API to open the files or folders your app would need to access while having no filesystem permissions at all. You can access the camera, microphone, and GPS without the user devices portal, by simply using the respective portals where the user has the power to allow or deny access to such devices as they wish.

      You can record the screen, take a screenshot, and pick a color in the screen by simply calling the proper portals, with the bonus that the user will be able to select if they want the entire screen, a specific window, or a specific area to be recorded/captured and whether the cursor should be shown or not.

      Heck, even TeamViewer can be as this restricted without losing any functionality if they use the Screen Cast portal which allows apps to mirror input from a remote device! They would of course need the network permission, but that’s still safe.

  • kuneho@lemmy.world
    303·
    1 year ago

    this sandbox craze is slowly pushing things back to the point where we used cartridges and booted off from them straight to the program. who needs an OS at this point? it’s bundled with the app anyway 😆

    /s, somewhat

  • soulfirethewolf@lemdro.idEnglish
    242·
    1 year ago

    It’s nice to see good app security being praised. Sometimes it feels like some people on lemmy (and the fediverse) throw security to the wind.

    Like one time I had heard someone over on Mastodon say that they thought that HTTPS was too overused and shouldn’t have been everywhere because it makes older apps unable to access sites and also made adblocking just ever so slightly harder.

    Which yeah, I love adblockers, but I’m definitely not comfortable with all traffic having to go unencrypted just for it.

    • IverCoder@lemm.eeOPEnglish
      352·
      1 year ago

      As well as FOSS too. Sandboxing is a security standard that should be followed by every software how open their code may be.

    • IverCoder@lemm.eeOPEnglish
      11·
      1 year ago

      This could well be an advanced video editor or an office suite if they take full advantage of the portals API without losing any functionality. Well, they can have the network permission, it would still be safe anyway.

      • owsei@lemmy.world
        21·
        1 year ago

        I agree with you

        however this program can’t even create files, although I may have misunderstood it

        how are you supposed to save your work?

    • IverCoder@lemm.eeOPEnglish
      171·
      1 year ago

      An app should not be able to access stuff the user did not consent to letting access.

        • IverCoder@lemm.eeOPEnglish
          3·
          1 year ago

          The file picker API is there to allow apps to access and save files with the user’s consent, while bot having any filesystem access. So a properly sandboxed app would be able to open, edit, and save files wherever the user wants, while not having access to any other irrelevant files, such as your .bashrc or memes folder.

        • SuperIce@lemmy.worldEnglish
          11·
          1 year ago

          Even if I trust the app, it may have security bugs. Still better to have it sandboxed.

        • IverCoder@lemm.eeOPEnglish
          3·
          1 year ago

          Well, no matter how I trust my photo editing app, it has no business accessing my thesis documents. Proper filesystem sandboxing does security properly.