Closed Bug 1682462 Opened 3 years ago Closed 11 months ago

policies.json in Firefox flatpak

Categories

(Core :: Widget: Gtk, enhancement)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 85
Platform:
Desktop
Linux
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: theevilskeleton, Assigned: mkaply)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Bug 1682462 - Allow Flatpak to access sytem policies. r?mtabara!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1682462 - Revert policy access change that doesn't work. r?mtabara!
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Expected results:

I'd like to request the feature to utilize policies.json's in the Firefox flatpak. I don't think this can be done in the flatpak yet.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Component was set for this enhancement in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one

Status: UNCONFIRMED → NEW
Ever confirmed: true

I'm honestly not even sure how this stuff works.

Can the Flatpak read anything outside of its directory?

Like etc or something like that?

(In reply to Mike Kaply [:mkaply] from comment #3)

I'm honestly not even sure how this stuff works.

Can the Flatpak read anything outside of its directory?

Like etc or something like that?

The only directory it has direct access to is the Downloads directory.

OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Version: Firefox 84 → Firefox 85

Martin: how does it get access to downloads?

Could we somehow provide access to etc/firefox/policies?

How do other Flatpaks handle enterprise policy?

Flags: needinfo?(stransky)

Hi, that depends on flatpak build script, you can allow access to anywhere you want. So yes, access to /etc/firefox/* should be granted for reading by flatpak sandbox. This needs to be done on Mozilla flatpak build script. Mihai, I guess we need to add it to https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh right?

Flags: needinfo?(stransky) → needinfo?(mtabara)

(In reply to Martin Stránský [:stransky] from comment #6)

Hi, that depends on flatpak build script, you can allow access to anywhere you want. So yes, access to /etc/firefox/* should be granted for reading by flatpak sandbox. This needs to be done on Mozilla flatpak build script. Mihai, I guess we need to add it to https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh right?

Apologies for delays in replying here.

Yes, it should be possible. IIRC we already grant a set of permissions at build generation time, such as pulseaudio, access to X11 or the network. If I read the docs right, we can extent that via the filesystem directive. Seems like we already do that for access a specific XDG folder in here. Sounds like adding --filesystem=/etc/firefox/policies might solve it if that's where the policies.json file ends up being.

Flags: needinfo?(mtabara)
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/444f30000d44
Allow Flatpak to access sytem policies. r=mtabara

https://hg.mozilla.org/mozilla-central/rev/444f30000d44

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox87: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

Comment in phabricator says this won't actually work. Reopening so we can verify that.

"Just a heads up – this is not going to work. There is --filesystem=host-etc but that exposes full /etc at /run/host/etc (and bumps flatpak version requirement), also Firefox would need to create a symlink from /run/host/etc/firefox to in-sandbox /etc/firefox."

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
status-firefox87: fixed → ---
Target Milestone: 87 Branch → ---

It's easy to test:

> flatpak run --command=stat org.mozilla.firefox//beta /etc/firefox/policies
stat: cannot statx '/etc/firefox/policies': No such file or directory

> flatpak info -m org.mozilla.firefox//beta | grep /policies
filesystems=xdg-download;/etc/firefox/policies;

To expand on my comment from Phabricator, /app/bin/firefox is already a shell script. After adding --filesystem=host-etc to build-finish, it would be enough to add ln -s /run/host/etc/firefox /etc/firefox there.

Adding --filesystem=host-etc would introduce sandbox hole and I don't think exposing whole /etc in order to access one file is rational. You may look at what chromium flatpak did: https://github.com/flathub/org.chromium.Chromium#orgchromiumchromiumpolicy however this is complicated and not exactly what users may expect.

Which is why I mention host-etc. It's what users expect.

Yes but it was considered as even worse solution.

Sorry, considered by who exactly? It's exactly what it's for, to expose files from /etc. There is nothing philosophical about it.

By people from Endless os who made chromium flatpak. Making an effort to provide flatpak friendly solutions in apps would look like waste of time if disabling sandbox is accepted without second thoughts. Some consistency would be appreciated.

I'm not touching any philosophy whatever it means here. My point was written above so let me repeat it: I don't think exposing whole /etc in order to access one file is rational.

(In reply to Emerson Bernier from comment #13)

Adding --filesystem=host-etc would introduce sandbox hole and I don't think exposing whole /etc in order to access one file is rational. [...]

I'm not a security expert and this might be off-topic, but how so? Writing in /etc requires root access, and no Flatpak bundle comes with a program that can potentially give root access inside the sandbox.

[📦 org.mozilla.firefox ~]$ su
bash: su: command not found
[📦 org.mozilla.firefox ~]$ sudo
bash: sudo: command not found

I didn't write it gives you straightforward root access (in such case that option would be nonsense). I said it exposes whole /etc so app can read all system configs and some of them may be sensitive.

Side issue is that host-etc exist only since flatpak 1.8 so it won't help for users of non-recent distros unless the get latest flatpak frpom somewhere.

Would there be any opposition to assigning --filesystem=/etc/firefox/ to the default Flatpak permissions? You can define the exact system directories that you want to be able to access from the sandbox, without having to rely on a special parameter, or accessing the entirety of /etc.

Per comment 11 (https://bugzilla.mozilla.org/show_bug.cgi?id=1682462#c11) that won't work.

we already add /etc/firefox/policies to the flatpak permissions:

https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh#150

But it doesn't give us the access (as far as I know)

I looked into it and I now see that yes, etc-host is required because /etc is blacklisted otherwise.

(In reply to Mike Kaply [:mkaply] from comment #22)

Per comment 11 (https://bugzilla.mozilla.org/show_bug.cgi?id=1682462#c11) that won't work.

we already add /etc/firefox/policies to the flatpak permissions:

https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh#150

But it doesn't give us the access (as far as I know)

I recommend to revert commit which added /etc/firefox/policies in flatpak permissions. It has no purpose and confuses people.

(In reply to Emerson Bernier from comment #24)

(In reply to Mike Kaply [:mkaply] from comment #22)

Per comment 11 (https://bugzilla.mozilla.org/show_bug.cgi?id=1682462#c11) that won't work.

we already add /etc/firefox/policies to the flatpak permissions:

https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh#150

But it doesn't give us the access (as far as I know)

I recommend to revert commit which added /etc/firefox/policies in flatpak permissions. It has no purpose and confuses people.

I second this.

Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/d67394aeba45
Revert policy access change that doesn't work. r=mtabara DONTBUILD

So does anyone have any thoughts as to the right way to do this?

Hi folks, I helped with the original Flatpak for Firefox and happy to help here too in terms of the Flatpak parts. I think @mkaply is heading in the right direction with an extension point; Flatpak apps tend towards not using system-wide configuration. Instead by defining an extension point, the the administrator / OS can arrange for system-wide policies to be placed in "unmanaged extensions" (ie folders which get treated as extensions) in /var/lib/flatpak or symlink back to the host's /etc paths etc - so it's more flexible for the Flatpak to bring these system files via extensions.

The problem is that, if I understand correctly, Firefox can only read one policies.json file, and the Flatpak already provides one in order to prevent Firefox from attempting to auto-update (and giving the user prompts they cannot do anything about) and disabling the default browser check. So we need to figure that out before worrying about how we get the policies.json file into the sandbox, in a place that Firefox will read.

Is there any way to achieve the same policies inside Firefox as code (ie detecting the Flatpak environment - which can be as easy as checking for the existence of /.flatpak-info) to vary these behaviours, and then we would "free" the policies.json to be provided through an extension point. Or, alternatively (which is how Chromium works I think, so the extension behaviour for Flatpak is simpler) is there any provision for Firefox to read and merge multiple policy files so we could have a stack of the Flatpak policies, those from the system, those from other extensions, etc?

IF we removed the policies.json in the Flatpak, could the Flatpak access an external system point to get the policies?

Yes, we might need to patch in (or influence at runtime - environment variable?) a Flatpak-specific path that would be an extension point under /app which the admin can use to feed in a policies.json from outside. We could potentially also emulate with a small script which merged the Flatpak policy settings into the external file and produced a merged policies.json at runtime, but it would be cleaner if the updater/default check worked as intended when running under a Flatpak.

Any update on this? I was really sad to see that the original changes didn't work and we still don't have an option to configure this like we can with distro provided Firefox, or Snap.

Unfortunately I don't know enough about how to get this working in Flatpak. I'm surprised it's not as easy to add an external access point as it is with the Snap...

Blocks: 1785278
See Also: → 1795998
No longer blocks: 1785278

This was fixed by https://phabricator.services.mozilla.com/D168803

Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1814897

Status: REOPENED → RESOLVED
Closed: 3 years ago → 11 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: