Talk:Flatpak

From ArchWiki

To do

  • How to add / delete a repo
  • List of repos?
  • Installing / updating / removing flatpak applications
  • Building flatpak applications
  • Briefly mention differences with pacman and pros/cons
As a beginner, my main question coming here was "how is this different from pacman", and I did not find an answer. Gloomy (talk) 17:10, 3 August 2020 (UTC)Reply[reply]


Why are we documenting basic usage such as listing repos when that is better handled by upstream documentation such as http://flatpak.org/index.html#users TingPing (talk) 17:34, 8 December 2016 (UTC)Reply[reply]

Permissions / sudo conventions

Can there be information added regarding the --system and --user flags, as well as proper use of sudo for installing and running flatpak applications? As a new flatpak user, it's not clear to me what the conventions are for installing user applications (skype, feedreader, etc) especially since flatpak defaults to --system, requiring sudo to install and subsequently requiring sudo to run the application. Stephen304 (talk) 13:37, 13 November 2017 (UTC)Reply[reply]

Assuming Polkit is correctly configured you never need to explicitly use sudo. If you have admin and it is a single user system it really doesn't matter which you choose. TingPing (talk) 16:20, 13 November 2017 (UTC)Reply[reply]
I think it would be useful to note that applications installed without the --user flag (and therefore defaulting to --system) require sudo to install as well as run, while adding the --user flag when installing allows installing as non-root and running without sudo. It took me a while to realize that as the permissions error message without sudo and with --system default made me think that I had no choice but to install with sudo, and then I was confused when I had to also run with sudo. I figure this information would be very useful to other users getting started with flatpak for the first time. Stephen304 (talk) 13:49, 14 November 2017 (UTC)Reply[reply]
Bad phrasing, it does not require sudo it requires admin access via polkit or sudo. TingPing (talk) 16:25, 15 November 2017 (UTC)Reply[reply]
That doesn't really change that I still was confused, other people probably share that confusion, and the fact that the Flatpak page lacks any mention of the --user flag outside of the "Creating a custom base runtime" section. I think it's worthy of a mention in "Managing runtimes and applications", especially under "Install a runtime or application", where I would wager most people new to Flatpak will be looking at when trying to install applications like Feedreader and other desktop applications that would be easier to install and use when installed in the user context. Stephen304 (talk) 10:12, 16 November 2017 (UTC)Reply[reply]

Why is an arch-based runtime unsuitable?

This page says I shouldn't use an arch-based runtime to distribute apps with flatpak. I am interested in packaging some software which is best supported as AUR packages for use on other distos.

So why shouldn't I be using arch as a base? I am thinking to try it anyway and remove that warning if it works out. Akvadrako (talk)

Packages should use common runtime when possible. Then users will not need to download and install different runtimes again and again. So the warning should stay even when all is working well using arch runtime. --Fengchao (talk) 13:27, 7 January 2023 (UTC)Reply[reply]

Clarify or remove misleading warning regarding Flatpak's sandbox

In the main page, there is this warning in particular:

Warning: Flatpak applications are not effectively sandboxed by default, even when the package comes from flathub. Flatpak applications allow access to user files in $HOME and sandbox escape through X11 is trivial. [1] Therefore, rather than a sandbox, Flatpak is more accurately described as a container runtime environment.

Which was quoted and frequently edited by User:Alad. This is really vague by itself, because it doesn't apply to all apps. About half (arguably more) the apps don't allow access to $HOME, as seen by Flatstat.

I read the article, and here's my incomplete response:

In short, a sandbox provides an isolated runtime environment that restricts the process to allow only the minimal required actions (Principle of least privilege).

This is not entirely true. The Chromium Sandbox page linked in the article explicitly says that it's an overview of Chromium's sandbox and explains its philosophy, not sandbox by itself. In that overview, they say that one of their design principles is "principle of least privilege", which also implies "that restricts the process to allow only minimal required actions" from the quote. This means that we can get rid of this part, as it's not entirely true.

Now that we know that a sandbox does not always have to do with principle of least privilege, there's an immediate contradiction here:

  • The article is titled "Flatpak is not a sandbox"
  • In the article, I quote:

    In short, a sandbox provides an isolated runtime environment that restricts the process to allow only the minimal required actions (Principle of least privilege).

  • Later in the article, they state:

    Flatpak provides an isolated runtime environment using a container type sandbox to execute the target application inside.

  • And then:

    So why is flatpak not a sandbox?

The author claims that it's not a sandbox, and then proceeds to explain why Flatpak's sandbox isn't as restrictive; this is a sandbox. Being less restrictive than it could be is a different problem.

As for being "effectively sandboxed". This is misleading - many apps are effectively sandboxed, but many are not. The best thing to do is guide the user into understanding which one is well sandboxed and which one is not.

A flatpak app that is completely restricted but can access X11 simply needs to tell the X11 server to type ./exploit into another unconfined application window and that’s it. Its easy to test yourself[7].

I just tried the script it linked and it doesn't work:

❯ ./X11Injection.sh 
./X11Injection.sh: line 7: xdotool: command not found
./X11Injection.sh: line 8: xdotool: command not found
./X11Injection.sh: line 9: xdotool: command not found

So I need to install an app? But this is a host app, not a flatpak. And even then, if you're going to make arbitrary changes to your system, then we might as well not call Chromium a sandbox. I can easily disable GPU and setuid sandboxes. This doesn't make Chromium not a sandbox, doesn't it? Again, this needs to be explained.

Like I said, it's an incomplete response. I could continue, but the point I'm making is that the warning is misleading because it's generalized and not elaborated, and the article gets many things wrong right off the bat. We should either be extremely clear about it, or get rid of it entirely.

--TheEvilSkeleton (talk) 18:00, 12 May 2023 (UTC) TheEvilSkeletonReply[reply]

This post seems to take issue mostly with wording and not with the presumably intended message of the warning. The reason for this warning is to make users aware of the fact that they should not rely on flatpaks isolation when installing possibly untrusted aphttps://wiki.archlinux.org/index.php?title=Flatpak&diff=778145&oldid=778112plications or doing risky operations (like opening suspicious files). The article talks about long known issues of Linux desktop systems and demonstrates how some of the most common sandbox escape path work using commonly available tools. A real exploit would not rely on xdotool or any other used scripts, but rather implement this directly into the payload. Since the vast majority of flatpak applications allow either insecure file access, X11 access or device access and either one of these can be used to escape all isolation flatpak might provide, this warning is not misleading at all. Fuhu83 (talk) 21:30, 15 May 2023 (UTC)Reply[reply]
The warning was modified but then reverted with Special:Diff/778145. As far as I can tell both versions tell the same story, but one focuses on the applications (with differently configured permissions) and the other on Flatpak itself. To me the statement "secure by default" is hard to prove and should at minimum be clarified with the default permissions one gets when creating a new Flatpak application. The statement "security by obscurity" is also dubious.
I think everyone can agree that the warning should at least refer to 1. lax permissions of Flathub applications 2. what these lax permissions mean in practice 3. the ability to configure them with Flatpak#Override_sandbox_permissions_of_applications. -- Alad (talk) 11:34, 17 May 2023 (UTC)Reply[reply]
Agreed! The warning should inform users not to assume any effective sandboxing is enforced when they install a flatpak applications. Pointing to some theoretically secure default that only exists when a flatpak maintainer creates an app is extremely misleading and has nothing to do with the isolation to be expected from a flatpak application that is downloaded from a place like flathub. One commonly cited reason why users install flatpak is that they believe they "do not need to trust the application not to do harmful things", which is a misconception of how flatpak works. The maintainer determines the sandbox default sandbox settings and flatpak encourages the developer of an app to also be the flatpak maintainer, which removes any traditional checks from a third party. Even assuming that the user knows how to change the permissions to prevent trivial sandbox escape (unlikely the case), the warning would still be valid since it addresses the default permissions present at installation time.
Frankly, if anything there should be a lot more warnings here (and in similar "security" applications) because the term sandboxing is without strict definition. The level of isolation provided by flatpak, even under the most favorable conditions (no file access, no X11, no devices, no IPC ...), does not come close to the established sandbox architectures like those present in Openssh or modern browsers. Isolation of the kernel attack surface (system calls) is nearly nonexistent in flatpak and impossible to implement on the same level as native seccomp integration directly into the application code. Flatpak uses container technology to provide limited isolation that would be more appropriately described as a safety measure protecting against accidental changes to system resources and not as something that provides protection against actual attacks like what Chromium or Firefox do. Perhaps this whole sandboxing topic should get a page of its own? Fuhu83 (talk) 16:34, 17 May 2023 (UTC)Reply[reply]
@TheEvilSkeleton: You haven't actually made any valid arguments about why the warning is incorrect. You argue about the general definition of sandbox here which is completely irrelevant since the linked article only uses this for introductions and it has nothing to to with the issue at hand. It would be great if you could at least try to read the entire reference before editing a related warning simply because you didn't like what someone said about your favorite app. -- JohnSnow (talk) 21:49, 18 May 2023 (UTC)Reply[reply]
@JohnSnow nobody here has made any valid arguments for why the current warning is correct either. The warning right now is just plain incorrect, and implies the Flatpak sandbox is, by default, insecure. This is not true. Some (most, really) applications may require insecure permissions, but this does not completely nullify the sandbox; with the recent "fractureiser" malware, only the Prism Launcher Flatpak was completely unaffected. It does not allow access to the required paths for the malware to function. Other sandbox escapes are possible (/dev/pts/, for example) but, with some improvements, the malware would be completely ineffective inside of the sandbox. The sandbox was secure by default, with Prism Launcher opting out of /dev sandboxing for GPU acceleration and controller support. Eventually, when the Linux desktop moves forward and improves enough, vulnerabilities such as this will be near-impossible to abuse. To restate my point, the Flatpak sandbox *is* secure by default; some applications just don't play well with it, and disable some aspects of it as a result. This does not mean the Flatpak sandbox is insecure by default, it means applications are. -- Oro 20:30, 7 June 2023 (UTC)Reply[reply]
As I explained above, the text warns about flatpak applications from places like flathub since their default sandbox seetings are completely up to the maintainer. Nobody here is talking about the theoretical flatpak defaults, your whole argument is a straw man fallacy and does not address the actual warning or reason. If you would like to improve the text, feel free to suggest a better wording here on the discussion page. Fuhu83 (talk) 21:18, 7 June 2023 (UTC)Reply[reply]
No. The warning warns against the default *Flatpak* sandbox, not the default *Flatpak applications from Flathub* sandbox. Everyone here but me and TheEvilSkeleton are saying that the default Flatpak sandbox is insecure. What I added to the article words this properly and gets the point across that some Flatpak applications are not sufficiently sandboxed to be completely secure. -- Oro 21:23, 7 June 2023 (UTC)Reply[reply]
Your changes are not addressing the problem at hand and seem to focus only on RP and justifications. As the previous discussion shows, there is a clear consent that a proper warning about not expecting secure sandbox default in practical flatpak applications should be part of this wiki. Adding endless text about the reasons for insecure defaults is not an appropriate use of this warning block. Considering your continued abuse of this wiki, it seems clear that you have no interest in a useful and neutral description of this program. Fuhu83 (talk) 21:37, 7 June 2023 (UTC)Reply[reply]
Your constant reverts also say that you aren't interest in a neutral description of it too. if you want it to be more neutral, modify my warning such that it's more neutral but does not say that the default flatpak sandbox is insecure. -- Oro 21:42, 7 June 2023 (UTC)Reply[reply]
The warning already states: "Flatpak applications are not effectively sandboxed by default." This is in no way the same as "default flatpak sandbox is insecure". Give me a minute to propose a new text and perhaps we can have a constructive discussion Fuhu83 (talk) 21:46, 7 June 2023 (UTC)Reply[reply]


Proposal for better wording: Fuhu83 (talk) 21:56, 7 June 2023 (UTC)Reply[reply]

Warning:
  • Many Flatpak applications available on flathub are not effectively sandboxed by default [2]. Do not rely on the provided process isolation without first reviewing the related flatpak permission manifest for common sandbox escape issues.
  • Running untrusted code is never safe; sandboxing can change this.
Could use some rewording, but it's definitely better. I wouldn't link to the "Flatpak is not a sandbox" article, as it's mainly just spreading misinformation and the author is twisting the meaning of the word "sandbox" to fit their own definition. The applications that don't have adequate sandboxing also depends on what you need them to do and what toolkit they use; GTK apps, for example, are normally fine with the default sandbox.
I suggest the following:
Warning:
  • Some applications are not compatible with a sandboxed environment, and as such may be able to modify the host system. Do not rely on Flatpak's provided process isolation without first reviewing the related Flatpak permission manifest for common sandbox escapes, and tweaking them as desired.
  • Running untrusted code is never completely safe; sandboxing cannot change this.

-- Oro 22:08, 7 June 2023 (UTC)Reply[reply]

Your wording here is technically correct, but it is still focused on shifting blame away from flatpak. This would be fine when addressing developers to explain the reasons behind it, but the warning is intended for users who find this page to learn about using flatpak on arch and not for developers. It is not relevant if an application is theoretically incompatible with the sandbox model or the flatpak maintainer just didn't know any better, both are reasons for insecure defaults today. The user needs to know that installing a flatpak application does not mean it comes with any secure defaults. In a second step, pointing to additional information about what sandbox escapes are and how they can be fixed adds value to the page as well. The linked article does present these information and while you may disagree with definitions, there does not seem to be anything wrong with the contents that are relevant here. If you have another source that explains sandbox escapes and how to test flatpak for them, feel free to propose it. Fuhu83 (talk) 22:23, 7 June 2023 (UTC)Reply[reply]
"...both are reasons for insecure defaults today." Yes and no. The *vast majority* of applications that have very weak sandboxing are applications that just aren't compatible with a sandbox, and the maintainers give the needed permissions for them to work out of the box. Another source would be nice, but everything that exists right now is more just trying to spread misinformation about Flatpak; I don't want to use something that, overall, spreads misinformation but has a few good points. As I know a decent amount about the sandbox, I may write my own blog post on this that may be used as reference. Would that work? For the time being, my suggestion may be the best solution. -- Oro 22:30, 7 June 2023 (UTC)Reply[reply]
Looking at the current chromium manifest, it seems they still permit full $HOME access by default, despite the file portal being available, so it does not seem that this needs to be. For this warning however, the only relevant issue is whether the default manifest from flathub will provide any effective isolation. Considering that more then 50% of all flathub apps still allow X11 access, its safe to say that the *vast majority* of flatpak applications on flathub are not effectively sandboxed. My wording is already toned down to "many" and that is certainly more correct that mentioning "some". I don't mind compromising the warning by removing the source if you can actually point out anything in there that is incorrect other then some definition you don't agree with. Also, please take some time to consider how you can actually improve the flatpak ecosystem to fix these issues. Calling any criticism of flatpak misinformation will do nothing but to push new users away instead. Fuhu83 (talk) 23:07, 7 June 2023 (UTC)Reply[reply]
Do not censor the wiki just because someone does not like the source. Nobody here has pointed out anything that is objectively wrong with it yet. Until there is a better link to explain the issue, it should stay on the page. The new text from Fuhu is alright, even if the warning should probably be more severe. -- JohnSnow (talk) 10:52, 8 June 2023 (UTC)Reply[reply]
I will go ahead and add the warning text that all seem to consider an improvement for now, but we could discuss a different source to explain the issue when one is proposed. @Oro If you come around making a blogpost with more comprehensive instructions, feel free to suggest it as a new reference here and we can discuss Fuhu83 (talk) 11:13, 9 June 2023 (UTC)Reply[reply]