Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox under Firejail can't make new connections after switching network connection methods #5010

Closed
6 of 7 tasks
alexdelorenzo opened this issue Mar 5, 2022 · 58 comments · Fixed by #5591
Closed
6 of 7 tasks
Labels
bug Something isn't working

Comments

@alexdelorenzo
Copy link

Description

After using Firefox for a bit on WiFi and then experiencing a network failure, when I go to change my network connection method to Ethernet, I cannot open or refresh pages in Firefox.

Connections will time out and I'll have to close the browser and open it again in order to load or refresh pages.

Steps to Reproduce

Open Firefox with Firejail, let it run for a bit. After experiencing a network connection error, change your connection via a separate network device. Go back to Firefox and try to open "google.com".

Expected behavior

I should be able to resume using the browser after experiencing a network failure and/or network device change.

Actual behavior

After network failure/network device change, trying to open new pages or refreshing tabs results in those tabs eventually timing out without loading. The browser must exit and start again for it to work.

Behavior without a profile

This does not seem to be an error with Firejail-less Chromium or when I've tried to replicate the issue in Firefox without Firejail.

Additional context

Environment

  • Manjaro unstable
  • firejail version 0.9.68

Checklist

  • The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
  • I can reproduce the issue without custom modifications (e.g. globals.local).
  • The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
  • The profile (and redirect profile if exists) hasn't already been fixed upstream.
  • I have performed a short search for similar issues (to avoid opening a duplicate).
    • I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
  • I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Log

Output of LC_ALL=C firejail /path/to/program

$ LC_ALL=C firejail firefox  --new-instance --profile "tmp" --private-window "https://imgur.com" 
Reading profile /etc/firejail/firefox.profile                                                                                                                 
Reading profile ~/.config/firejail/firefox.local                                                                                                     
Reading profile /etc/firejail/whitelist-usr-share-common.inc                                                                                                  
Reading profile /etc/firejail/firefox-common.profile                                                                                                          
Reading profile /etc/firejail/disable-common.inc                                                                                                              
Reading profile /etc/firejail/disable-devel.inc                                                                                                               
Reading profile /etc/firejail/disable-exec.inc                                                                                                                
Reading profile /etc/firejail/disable-interpreters.inc                                                                                                        
Reading profile /etc/firejail/disable-proc.inc                                                                                                                
Reading profile /etc/firejail/disable-programs.inc                                                                                                            
Reading profile /etc/firejail/whitelist-common.inc                                                                                                            
Reading profile /etc/firejail/whitelist-run-common.inc                                                                                                        
Reading profile /etc/firejail/whitelist-runuser-common.inc                                                                                                    
Reading profile /etc/firejail/whitelist-var-common.inc                                                                                                        
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,                                                                                        
Ignoring "dbus-user.own org.mozilla.Firefox.*" and 2 other dbus-user filter rules.                                                                            
Parent pid 690627, child pid 690628                                                                                                                                                                                                                          
Warning: logind not detected, nogroups command ignored                                                                                                        
Warning: logind not detected, nogroups command ignored                                                                                                        
Warning: logind not detected, nogroups command ignored                                                                                                        
Warning: /sbin directory link was not blacklisted                                                                                                             
Warning: /usr/sbin directory link was not blacklisted                                                                                                         
Warning: logind not detected, nogroups command ignored                                                                                                        
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,                                                                                        
Warning: logind not detected, nogroups command ignored                                                                                                        
Child process initialized in 96.16 ms  

Output of LC_ALL=C firejail --debug /path/to/program

output goes here

@rusty-snake
Copy link
Collaborator

Does it work if you enter a ip address in the urlbar? https://1.1.1.1/ for example
i.e. is this a DNS problem or a network problem.

@JMillz269
Copy link

JMillz269 commented Mar 5, 2022

I have a very similar (maybe same?) issue. Running "firejail firefox" has no internet connection but "firejail --noprofile firefox" does have internet. Entering that IP address in the urlbar does load a page and works as well.

@rusty-snake
Copy link
Collaborator

If you use openSUSE: #4954

@JMillz269
Copy link

I use Arch with networkd, not openSUSE. But the fix listed there worked. Whitelisted /etc/resolv.conf and all is well. Thanks!

@rusty-snake
Copy link
Collaborator

Where does your /etc/resolv.conf point to? We should whitelist that path too.

@JMillz269
Copy link

It points to /run/systemd/resolve/stub-resolv.conf. This is already in the whitelist file.

@e-pirate
Copy link

e-pirate commented Mar 6, 2022

I'm having same problem after updating from firejail-0.9.64.4 to firejail-0.9.68.
If FF is running inside new firejail-0.9.68 it will not connect anywhere if network changes (after reconnecting to a different WiFi network for example). If I start VPN, all resources will not be accessible for FF. After restarting FF (still inside firejail-0.9.68) while connected to a "new" network/VPN, FF will start working as usual. Besides I have some corporate messengers running inside firejail to prevent them from doing nasty things and firejail-0.9.68 do not affect messengers - they will continue to work after connecting to "new" network and without restarting. Seems that this issue affect only FF. Besides, I can definitely confirm that this issue appeared after firejail update and affects all versions of FF I have.
I tested FF running without firejail and connecting to different networks make no effect on FF, it will continue to work.
I checked me update logs and confirmed what I suspected - firejail was updated recently. So I rolled back to 0.9.64 and all problems gone. Now FF having no problems after network reconnection. All configs are same.
To draw the line: this seems firejail-0.9.68 problem related to FF only.

@rusty-snake
Copy link
Collaborator

@e-pirate #5010 (comment)

@e-pirate
Copy link

e-pirate commented Mar 7, 2022

@rusty-snake https://1.1.1.1 is accessible with 0.9.68 while other sites by their names are not. Looks like a DNS problem.

@rusty-snake
Copy link
Collaborator

Which distro do you use? Which program manages your DNS config? Where does you /etc/resolv.conf point to? Do you use nss_dns or nss_resolve first?

@alexdelorenzo
Copy link
Author

Does it work if you enter a ip address in the urlbar? https://1.1.1.1/ for example i.e. is this a DNS problem or a network problem.

I'll let you know if it happens again or if I'm able to replicate it. I don't remember exactly, but I do have some vague memory of trying to access a machine on my network at 10.0.4.1 and it not working, but I could be wrong.

@e-pirate
Copy link

e-pirate commented Mar 8, 2022

Which distro do you use? Which program manages your DNS config? Where does you /etc/resolv.conf point to? Do you use nss_dns or nss_resolve first?

Gentoo. I believe that NetworkManager is handling my DNS configuration. resolv.conf point to correct set of DNS servers all the time.
I can confirm, that the problem affects only FF and only with firejail version 0.9.68.

@rusty-snake
Copy link
Collaborator

If this happens, can you still open file:https:///etc/resolv.conf in a new tab? Does it work if you enable DoH in firefox?

@fuine
Copy link

fuine commented Mar 9, 2022

I can reproduce this bug on Arch with FF and firejail version 0.9.68. Downgrading to 0.9.64.4 solves the issue. In my case I can open file:https:///etc/resolv.conf in a tab. With 0.9.68 the content of this file doesn't change in firefox after changing the network, even though the file changes on disk. So from FFs point of view the file never changes and so the dns setup is wrong. Version 0.9.64 works as expected, that is the content of file:https:///etc/resolv.conf changes accordingly to the actual /etc/resolv.conf

@alexdelorenzo
Copy link
Author

I encountered this bug again, and was able to load pages via IP addresses. I didn't check /etc/resolv.conf, but what @fuine describes would explain the behavior that I experienced.

The DNS servers that are set for my first network configuration are only available on that network, and I switched to a second connection where I couldn't reach them. /etc/resolv.conf remaining the same between network changes from Firefox's view would do that.

@rusty-snake
Copy link
Collaborator

As a workaround it should work with

echo "whitelist $(dirname "$(readlink /etc/resolv.conf))" >> whitelist-run-common.local

@rusty-snake
Copy link
Collaborator

rusty-snake commented Mar 10, 2022

Related: #3649
edit: and #1889

@e-pirate
Copy link

As a workaround it should work with

echo "whitelist $(dirname "$(readlink /etc/resolv.conf))" >> whitelist-run-common.local

BTW, I noticed an error saying "unknown option --with-whitelist" or something like this while building 0.9.68 on Gentoo. Have no clue if this related or not, just FYI.

@rusty-snake
Copy link
Collaborator

unknown option --with-whitelist

* removal: --disable-whitelist at compile time

cc @hlein

if this related

It's not related.

@hlein
Copy link
Contributor

hlein commented Mar 11, 2022

unknown option --with-whitelist

* removal: --disable-whitelist at compile time

Aha, yup this should be fixed in Gentoo as of a few weeks ago (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0246df2ab9257ecb01fa6fc453a7c647cd1ca543). @e-pirate do you know if you were building firejail-0.9.68-r1.ebuild?

(If that's the version you were/are building and still see that error, please file a bug over at https://bugs.gentoo.org as it's a Gentoo packaging problem for me, not a firejail problem.)

@e-pirate
Copy link

unknown option --with-whitelist

* removal: --disable-whitelist at compile time

Aha, yup this should be fixed in Gentoo as of a few weeks ago (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0246df2ab9257ecb01fa6fc453a7c647cd1ca543). @e-pirate do you know if you were building firejail-0.9.68-r1.ebuild?

(If that's the version you were/are building and still see that error, please file a bug over at https://bugs.gentoo.org as it's a Gentoo packaging problem for me, not a firejail problem.)

Nop, I was building 0.9.68, because 0.9.68-r1 is marked unstable:

Keywords:    0.9.64.4:0: 
Keywords:    0.9.68:0: amd64
Keywords:    0.9.68-r1:0: ~amd64 ~arm ~arm64 ~x86

But I can still build 0.9.68-r1 and return to you with the result.

@hlein
Copy link
Contributor

hlein commented Mar 12, 2022

Nop, I was building 0.9.68, because 0.9.68-r1 is marked unstable:

Hah, right! I forgot that 0.9.68 got marked stable; as a proxy maintainer that is above my pay grade ;)

But I can still build 0.9.68-r1 and return to you with the result.

Thanks!

@e-pirate
Copy link

e-pirate commented Mar 12, 2022

Nop, I was building 0.9.68, because 0.9.68-r1 is marked unstable:

Hah, right! I forgot that 0.9.68 got marked stable; as a proxy maintainer that is above my pay grade ;)

But I can still build 0.9.68-r1 and return to you with the result.

I can confirm that there is no errors related to --disable-whitelist during 0.9.68-r1 build process, but the DNS problem remains. Downgraded to 0.9.64.4 again.

@hlein
Copy link
Contributor

hlein commented Mar 12, 2022

rusty-snake wrote:

As a workaround it should work with

echo "whitelist $(dirname "$(readlink /etc/resolv.conf))" >> whitelist-run-common.local

Did this workaround work for either @e-pirate or @alexdelorenzo ? Sounds like it did for JMillz269.

I can imagine some situations when it might not (generally: if the thing-managing-resolv.conf-links doesn't stick to one directory to store the pointed-to files). But I don't want to go down that rabbit hole unless confirmed we need to.

@rusty-snake
Copy link
Collaborator

I say we need a general solution for resolv.conf changes (see also #3649).

@alexdelorenzo
Copy link
Author

echo "whitelist $(dirname "$(readlink /etc/resolv.conf))" >> whitelist-run-common.local

Did this workaround work for either @e-pirate or @alexdelorenzo ? Sounds like it did for JMillz269.

No, it didn't. My /etc/resolv.conf is not a symlink, and /etc is not a valid whitelist path, as Firejail gives me this error:

Error: invalid whitelist path /etc 

Instead, I added this to ~/.config/firejail/whitelist-run-common.local:

whitelist /etc/resolv.conf

After relaunching Firefox, and switching networks to one that can't reach my DNS servers, my /etc/resolv.conf does not change in Firefox's view.

I tried the same thing with Chromium, and added the whitelist line to a firefox.local and chromium.local file to see if that would change anything for either app, and it doesn't.

The /etc/resolv.conf an app first sees is the file that remains between network changes, while my system's resolv.conf changes consistently.

@Nils-TUD
Copy link

As far as I can see this is a general issue and has nothing to do with the firefox profile or other profiles. When I run:

firejail --noprofile firefox

and open file:https:///etc/resolv.conf in firefox and then change the network, the content of the resolv.conf stays the same, as far as firefox is concerned.

I didn't find any workaround with 0.9.68 yet. However, downgrading to 0.9.66 solves the issue. In case it matters, I'm running on Arch and /etc/resolv.conf is no symlink in my case.

@alexdelorenzo
Copy link
Author

@Nils-TUD, what happens when you view /etc/resolv.conf from another browser, like Chromium, and change it?

@Nils-TUD
Copy link

With Chromium it's exactly the same: it always shows the same content for /etc/resolv.conf although it changed on disk.

@RalfJung
Copy link

RalfJung commented Apr 13, 2022

I am having the same problem for all my firejailed applications. (I had this problem for weeks but blamed it on the applications.) As far as I can tell, I don't even have private-etc set for these profiles. This is hard to debug since ping, host and so on fail to run even after I commented out the "disable-programs" include (no idea what is happening here).

Adding whitelist /etc/resolv.conf does not help. Removing netfilter does not help either.

It almost looks like firejail is doing something magic with /etc/resolv.conf and there is no way to disable that?
EDIT: Ah, #3649 explains it -- the file is replaced rather than changed by NetworkManager and somehow together with the /etc whitelisting that means the update is not propagated to the jail.

OTOH, in my case the DNS servers actually stay the same as I switch between Wifi and cable. And yet the applications lose connectivity. So I am not sure if DNS is the only problem and routing is not also affected? (As I said, hard to debug since none of the regular networking tools seem to work inside the jail.)

@DatAres37
Copy link

DatAres37 commented Sep 6, 2022

So not to sound rude or anything, but I hope you guys realize that this is currently a big issue for VPN users. I noticed this yesterday by accident: Run firejailed Firefox or Element -> activate VPN (for example Wireguard through NetworkManager) -> Your whole DNS traffic gets leaked to your standard DNS. This is especially a problem for users with a higher threat level and it makes me a bit worried how long this issue is already open without some users realizing it.

@glitsj16 glitsj16 added the bug Something isn't working label Sep 6, 2022
@glitsj16
Copy link
Collaborator

glitsj16 commented Sep 6, 2022

@DatAres37 Marking this as a bug. Hopefully that will bring this back to the attention of our devs. Thanks for your comment & patience!

@covex
Copy link

covex commented Nov 4, 2022

Found the same issue lately - the VPN changes to resolve.conf (NM manged) are not used in firejailed firefox.

Upgrade firejail-0.9.70-1.fc35.x86_64 @updates
Upgraded firejail-0.9.66-2.fc35.x86_64 @@System

Is there any solution for this - I did not found anything clear in this issue..

@rusty-snake
Copy link
Collaborator

@covex #5010 (comment)

@covex
Copy link

covex commented Nov 4, 2022

Hm, thanks, so it looks like I have to reconfigure NM and start local dns server to workaround a problem in firejail, right? Seems easier to downgrade the firejail...

@rusty-snake
Copy link
Collaborator

Downgrade to a vulnerable version ?! 😨

If the specific cause on your system was introduced with 0.9.70, ignore everything that causes this (depends on your DNS setup). My comment works generally as it is a working universal DNS setup.

RalfJung added a commit to RalfJung/firejail that referenced this issue Nov 4, 2022
@RalfJung
Copy link

RalfJung commented Nov 4, 2022

I still think ba9c969 should be reverted or at least be made opt-out, it just breaks too many things...

At https://github.com/RalfJung/firejail I have a version of 0.9.68 with the problematic patch reverted. Sadly that doesn't apply cleanly on 0.9.70 any more.

@gfarrell
Copy link

I've seen that there is a release candidate for 0.9.72, but that doesn't appear to contain a fix for this bug, which is currently preventing firefox working when I use my VPN (mullvad over wireguard) -- I have to kill and reopen firefox whenever my laptop sleeps or there there are any network changes.

Is there a plan to include a fix for this in 0.9.72?

@rusty-snake
Copy link
Collaborator

A fix is unlikely since nobody worked on it yet and it will be a lot work. Mitigations/Workarounds however should be considered.

@gfarrell
Copy link

I don't know the inner workings of firejail at all, but perhaps reverting ba9c969 is the best bet for the 0.9.72 release then? That seems like it would balance the work required with the gains of repairing the problematic behaviour.

@kmk3 kmk3 added this to To do in Release 0.9.72 Dec 20, 2022
kmk3 added a commit to kmk3/firejail that referenced this issue Jan 16, 2023
To avoid boolean confusion (`no-foo no` / `no-foo yes`) in
firejail.config:

    etc-no-blacklisted no
    etc-no-blacklisted yes

Commands used to search and replace:

    git grep -Ilz -i 'etc.no.blacklisted' -- etc src |
      xargs -0 -I '{}' sh -c "printf '%s\n' \"\$(sed \
        -e 's/etc-no-blacklisted/etc-hide-blacklisted/' \
        -e 's/ETC_NO_BLACKLISTED/ETC_HIDE_BLACKLISTED/' \
        '{}')\" >'{}'"

Added on commit ded5020 ("opt-in: skip blacklisted files in
private-etc - netblue30#5010, netblue30#5230", 2023-01-15) / PR netblue30#5591.
kmk3 added a commit to kmk3/firejail that referenced this issue Jan 16, 2023
To make it clearer.

Added on commit ded5020 ("opt-in: skip blacklisted files in
private-etc - netblue30#5010, netblue30#5230", 2023-01-15) / PR netblue30#5591.
kmk3 added a commit to kmk3/firejail that referenced this issue Jan 16, 2023
Let users know that enabling this may break /etc/resolv.conf.

Added on commit ded5020 ("opt-in: skip blacklisted files in
private-etc - netblue30#5010, netblue30#5230", 2023-01-15) / PR netblue30#5591.
kmk3 added a commit that referenced this issue Jan 16, 2023
@kmk3 kmk3 moved this from To do to Done (on RELNOTES) in Release 0.9.72 Jan 16, 2023
@gfarrell
Copy link

gfarrell commented Feb 3, 2023

I was very excited about 0.9.72 landing so that I could go back to using my VPN, but unfortunately it appears that this has not fixed the issue described here. I have recorded a screen recording demonstrating the behaviour in case that's useful.

In my firejail.conf I have etc-hide-blacklisted no (as is now default anyway). The only thing in my firefox.local is a whitelist for mutt's email output so I can see emails in a browser.

@rusty-snake
Copy link
Collaborator

  • The issue caused by ba9c969 (first release 0.9.70) is fixed now.
  • This was the cause affecting the most users.
  • There are a lot more causes as there are a lot more DNS configurations especially with VPNs.
  • To find a concept (=abstract solution) to properly handle resolv.conf instead of fixing causes one by one in a never ending iteration I opened Fixing the DNS resolv.conf issue #5607.

@e-pirate
Copy link

e-pirate commented Feb 5, 2023

Can you please make clear is 0.9.72 will work for NM managed VPNs?
UPD: updated to 0.9.72 and nop, Firefox still not working after connecting to a different wifi with same symptom - DNS servers are not updated. Bummer.

@kmk3
Copy link
Collaborator

kmk3 commented Feb 5, 2023

As mentioned by @rusty-snake, the original issue ("can't make new
connections after switching network methods") seems to have been fixed as of
0.9.72.

The issue with NetworkManager and VPNs might be related, but it is not the same
issue.

Please open a dedicated bug report for it so that it can be properly tracked:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Release 0.9.72
  
Done (on RELNOTES)