Is this blanket access really needed?

[CharString]

Can these lines in the Manifest be a bit more restrictive?

finish-args:
  - --filesystem=home
  - --filesystem=xdg-run/pipewire-0
  - --filesystem=/run/.heim_org.h5l.kcm-socket
  - --device=all

[TheEvilSkeleton]

Not really, unfortunately:

• --filesystem=home is used for PWAs;
• --filesystem=xdg-run/pipewire-0 is used for PipeWire, so it's only useful for Wayland users for screen sharing;
• --filesystem=/run/.heim_org.h5l.kcm-socket is used for Kerberos;
• --device=all is used for web cams, GPU acceleration, etc. It's not essential, but it's recommended.

[CharString]

You're right. I guess the sockets are okay. I'm unclear about the device=all.

[TheEvilSkeleton]

Perhaps we could disable device access, specifically enable GPU acceleration and disable home access, since the audience is completely different to those of Chrome or Chromium.

What do you think? We could create a poll in Reddit or in GitHub if you think we should restrict the permissions.

/cc @rany2

[CharString]

I'm a complete noob on flatpak. But the deb package I was using isn't updated anymore. So I was looking into how well this was sandboxed, before I'm installing this "window to arbitrary code on the web" :-) I have no idea whether we would need --filesystem=home:ro for uploading files and expanded with more specific write permissions to places like xdg-download, xdg-cache and xdg-data and such where needed.

I completely agree with you about the audience of this software. I expect them to willing to trade comfort for privacy/security. But asking them in a poll is better than taking my expectations :)

Up until now I have stayed away from flatpak precisely because the front-end is completely opaque about the level of sandboxing that is being done. Ideally these permissions are granted not at build time but at run time. A bit like you can install apk's on Android without granting any permissions, and you get prompted the moment an app tries to use one. That way, I, as a user, can somewhat judge whether I triggered the use, or some malware.

But then again, I might be different... I use the openssh agent, because the default one that comes with gnome doesn't support the '-c confirm before each use' flag. So a poll is better than this random guy from the internet.

[rany2]

If you'd like to harden this flatpak I suggest you use Flatseal. My main priority is to have this be usable for a decent amount of people out of the box. Most flatpak users would much rather things work out of the box than to fiddle around with flatpak override or Flatseal. This is also a FOSS application not some proprietary software so I'm less concerned about permissions

After all there are many other "complete noobs on flatpak" who would be at a loss when they realize something is broken because they need to give the flatpak permissions so it works. Also most of the time they might think the issue is that the flatpak is broken and not that it doesn't have the needed permissions

[CharString]

Thanks for the tip and patience.

[WhyNotHugo]

Can --filesystem=home somehow be narrowed down though?

I don't see why chrome needs to read .ssh/id_* or why is needs to be able to write into .profile. This basically give chromium the ability to completely hijack user sessions.

[rany2]

@WhyNotHugo https://github.com/flathub/com.github.Eloston.UngoogledChromium/issues/22#issuecomment-809499841

[Oymate]

@CharString regarding sandboxing see this: https://flatkill.org/ It's just a much more easier way to install chromium with drawbacks(which I accept)

[TheEvilSkeleton]

@Oymate the problem with this post is that it focuses on the wrong aspects of Flatpak. The static permissions we have right now is only a temporary workaround, and users can use Flatseal to manually change permissions, which the post does not mention at all. The developers are working on portals to fully sandbox applications, which is the long term solution. GTK >=3 apps and Qt >=5 apps generally use portals nowadays. I do agree that Flatpak does not have the best sandboxing implementation in the world yet, but it's definitely the best we have in the Linux desktop when it comes to having apps sandboxed OOTB, which does a good enough job to managing permissions thanks to Flatseal.

Another problem with this post is that it doesn't explain the sandboxing in Flatpak, but only its flaws, and makes it look like a huge problem. Apps that come with a traditional package manager is not sandboxed at all, so they're arguably a lot more insecure than an average Flatpak app.

Progress is not instantaneous; it takes time to get fully developed.

I do not recommend linking this post to people because flatkill gives the wrong image despite having few good points.

[WhyNotHugo]

I agree with @TheEvilSkeleton completely here.

It's also important to emphasise that these issues are really around Flathub and the packages hosted here (which have too open permissions, often negating the point of a sandbox completely). Flatpak itself does its job well, you just need to tweak which permissions each package have.

It's a shame that flatkill doesn't go into further detail explaining this: I'm sure there would be people interested in setting up their own Flatpak repository with security-oriented package definitions.

[Oymate]

There is also 2020 update which attempts to address that https://flatkill.org/2020/

[WhyNotHugo]

I agree completely on the first item there: "The sandbox is STILL a lie".

That's not a fault in Flatpak's design though -- it's an issue with the packages in this repository. Personally. I use Flatpak for some apps I'd rather isolate from my system (e.g.: Skype, 1Password, Chromium), and tweak the permissions a lot.

Flatpak itself is good, and, more importantly, moving in the right direction.

It's just a matter of time before a repository with security-oriented packages shows up. I'd set one up if I had the time, but honestly, I don't.

[CharString]

Apps that come with a traditional package manager is not sandboxed at all, so they're arguably a lot more insecure than an average Flatpak app.

That is a mute argument. My whole OS came from the same source. If I don't trust my distro, I should consider my box pwned. Unless you bootstrap your own C compiler, you can't even trust any software you compile yourself... That's possibly one of the reasons TempleOS is a thing.

[WhyNotHugo]

@CharString Some of us use Flatpak for applications that are not fully trusted. That is, things like Skype, Discord or Steam. I do trust my distribution packagers won't include secret backdoors in these packages -- but I'm also aware even they don't fully know what these binaries do.

Arguably, UngoogledChromium is on the safer side here though; it's unlikely there's obvious rootkits in it, but the attack surface is still huge, and I see no hard in defence in depth.