Open Bug 1682462 Opened 1 year ago Updated 5 days ago

policies.json in Firefox flatpak

Categories

(Core :: Widget: Gtk, enhancement)

Firefox 85
Desktop
Linux
enhancement

Tracking

()

REOPENED

People

(Reporter: theevilskeleton, Assigned: mkaply)

References

(Blocks 1 open bug)

Details

(Keywords: leave-open)

Attachments

(2 files)

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
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
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 → ---
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?

You need to log in before you can comment on or make changes to this bug.