Some of Firefox's security features may offer less protection on your

uphill · 2024-08-31 21:11:53

When arch uses the hardened linux kernel i get a messages in firefox telling me the security feature may offer less protection Some of Firefox's security features may offer less protection on your current operating system

how do i fix it?

Sorry if a simular post have been post I was not able to find anything simular.

Last edited by uphill (2024-08-31 21:12:52)

Strike0 · 2024-09-01 00:26:25

The reason is the hardened kernel disables user namespaces and FF wants to use them for sandboxing.
If you enable them with

sysctl -w kernel.unprivileged_userns_clone=1

the warning should be gone.
The point is though, they are disabled for a reason and even if FF handles them perfectly, other software may not.
So, YMMV.

Head_on_a_Stick · 2024-09-01 08:10:39

Strike0 wrote:

FF handles them perfectly

Lol. No.

Strike0 · 2024-09-01 09:12:49

Head_on_a_Stick wrote:

Strike0 wrote:
FF handles them perfectly
Lol. No.

Yes, I should have written "FF would handle them perfectly" instead.

The point is how FF manages to sandbox even code that tries to circumvent the related sandboxing. For more context an example: this 2024 kernel cve must be caught. It's one example of 44% of browser exploits found to rely on userns, at least on android, by google. One can learn from the blogpost that google uses secccomp-bpf filters to mitigate the risks on android and that's what FF does too. So, the problem to mitigate when enabling said kernel feature is twofold: 1. Does the FF sandboxing handle such CVE perfectly (enough) and 2. What about other software that your client system uses (e.g. other browsers too). That's my conclusion on YMMV to this point.

seth · 2024-09-01 09:14:54

Strike0 wrote:

even if FF handles them perfectly

There's merely a stray blank in there.
https://madaidans-insecurities.github.i … ux-sandbox

@uphill, disabling unprivileged_userns_clone is one of the major aspects of the hardened kernel
Using a FF flatpak might (idk) remove that warning but the main issue remains (maybe worse) because the local sandbox doesn't work inside bubblewrap and bubblewrap itself requries to be suid' to work with linux hardened.

Edit: F5kk

Last edited by seth (2024-09-01 09:15:32)

uphill · 2024-09-01 14:50:46

seth wrote:

Strike0 wrote:
even if FF handles them perfectly
There's merely a stray blank in there.
https://madaidans-insecurities.github.i … ux-sandbox
@uphill, disabling unprivileged_userns_clone is one of the major aspects of the hardened kernel
Using a FF flatpak might (idk) remove that warning but the main issue remains (maybe worse) because the local sandbox doesn't work inside bubblewrap and bubblewrap itself requries to be suid' to work with linux hardened.
Edit: F5kk

Whats more secure don't do anything, disables user namespaces or use Firefox in flatpak.

Trilby · 2024-09-01 15:13:53

Corporate training courses that had to give a quiz or exam to participants upon completion had a trend of including absurd answers among the multiple choice options. Like when there's a question about to whom a fire, or some other form of mishap should be reported, the correct answer is never Oprah. Having Oprah among the choices was meant to make the quiz easier for people to pass even if they slept through the training.

In the same way, anytime a question asks which option is more secure includes among multiple choice options anything related to flatpak, you can be sure that this is among the choices for the same reason Oprah was.

Security: Do nothing > Disable user namespaces > Call Oprah > Use flatpak.

Last edited by Trilby (2024-09-01 15:14:12)

seth · 2024-09-01 15:19:11

Security: Do nothing > Call Oprah > ENable user namespace clones > Use flatpak.

*Dis*abling unprivileged_userns_clone is equivalent to doing nothing when using the hardened kernel.

Also we don't want have the Oprah fans coming at us, do we?

Edit: https://bbs.archlinux.org/viewtopic.php?id=299020 might interest you.

Last edited by seth (2024-09-01 15:20:12)

Trilby · 2024-09-01 15:40:43

seth wrote:

Also we don't want have the Oprah fans coming at us, do we?

I'm not scared. It's not like they're Swifties.

EDIT: I've been out of the corporate world long enough now ... I suppose there's a pretty good chance Taylor Swift has replaced Oprah on these quizes.

Last edited by Trilby (2024-09-01 15:42:06)

seth · 2024-09-01 15:56:50

Taylor Swift gives away cars??!!

Strike0 · 2024-09-01 20:16:35

seth wrote:

Edit: https://bbs.archlinux.org/viewtopic.php?id=299020 might interest you.

Some FF commit suggests the warning may indeed have been added to accomodate for the apparmor-next feature, and they were trying to fix an inaccurate pre-FF129 userns detection.

In any case, clicking away the warning toggles (about:config) security.sandbox.warn_unprivileged_namespaces to false. So, if the do-nothing fix is chosen, it's easy to revert to do a Swift check of "Is it Over Now? (Taylor’s Version)".

ThoughtBubble · 2024-10-27 23:02:16

For a regular home user, would it suffice to disable user namespaces? Or is there something extra that I would need to do?

seth · 2024-10-28 06:25:21

Trilby wrote:

Security: Do nothing > Disable user namespaces > Call Oprah > Use flatpak.

seth wrote:

disabling unprivileged_userns_clone is one of the major aspects of the hardened kernel

Strike0 wrote:

clicking away the warning toggles (about:config) security.sandbox.warn_unprivileged_namespaces to false

Edit: for clarification, the disabled user NS in the hardened kernel are what causes this warning itfp and re-enabling them will allow FF and other clients to use userspace sandboxing again, but undermine the wider security efforts of the kernel. If you care about overall hardening of the system, you likely just want to click away that dialog.

Last edited by seth (2024-10-28 06:30:05)

Strike0 · 2024-10-28 23:23:18

I have since had a look what happens in Ubuntu 20.04. Being the home distro of the apparmor and snap projects, Firefox is per default installed as a snap package and has an enforced apparmor snap profile.

I noted that it's possible to explicitly disallow user namespaces (sysctl -w kernel.unprivileged_userns_clone=0) in Ubuntu and the Firefox warning does not appear. Hence, I conclude the Firefox detection triggering the warning is indeed erroneous and agree with Seth's clarification in #13.

loqs · 2024-10-29 00:32:25

Strike0 wrote:

I noted that it's possible to explicitly disallow user namespaces (sysctl -w kernel.unprivileged_userns_clone=0) in Ubuntu and the Firefox warning does not appear.

To crosscheck did you verify in firefox's about:support user namespaces is false and not enabled by apparmor?

Strike0 · 2024-10-29 09:41:33

loqs wrote:

Strike0 wrote:
I noted that it's possible to explicitly disallow user namespaces (sysctl -w kernel.unprivileged_userns_clone=0) in Ubuntu and the Firefox warning does not appear.
To crosscheck did you verify in firefox's about:support user namespaces is false and not enabled by apparmor?

Yes, with the following result (sorry, lengthy because I commented cases inline):

# Firefox 131.0.2 snap on Ubuntu 20.04

# default kernel settings 6.8.0-47-generic
kernel.apparmor_display_secid_mode = 0
kernel.apparmor_restrict_unprivileged_io_uring = 0
kernel.apparmor_restrict_unprivileged_unconfined = 0
kernel.apparmor_restrict_unprivileged_userns = 0
kernel.apparmor_restrict_unprivileged_userns_complain = 0
kernel.apparmor_restrict_unprivileged_userns_force = 0
kernel.apparmor_restrict_unprivileged_userns = 0
kernel.apparmor_restrict_unprivileged_userns_complain = 0
kernel.apparmor_restrict_unprivileged_userns_force = 0
kernel.unprivileged_userns_apparmor_policy = 1
kernel.unprivileged_userns_clone = 1

# Default about:support settings
Sandbox
Seccomp-BPF (System Call Filtering)	true
Seccomp Thread Synchronization	true
User Namespaces	true
Content Process Sandboxing	true
Media Plugin Sandboxing	true
Content Process Sandbox Level	4
Effective Content Process Sandbox Level	4

# after setting kernel.unprivileged_userns_apparmor_policy=0
kernel.apparmor_restrict_unprivileged_userns = 0
kernel.apparmor_restrict_unprivileged_userns_complain = 0
kernel.apparmor_restrict_unprivileged_userns_force = 0
kernel.unprivileged_userns_apparmor_policy = 0
kernel.unprivileged_userns_clone = 1
kernel.apparmor_restrict_unprivileged_userns = 0
kernel.apparmor_restrict_unprivileged_userns_complain = 0
kernel.apparmor_restrict_unprivileged_userns_force = 0
kernel.unprivileged_userns_apparmor_policy = 0
kernel.unprivileged_userns_clone = 1

# after setting sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1 and kernel.unprivileged_userns_clone = 0
kernel.apparmor_restrict_unprivileged_userns = 1
kernel.apparmor_restrict_unprivileged_userns_complain = 0
kernel.apparmor_restrict_unprivileged_userns_force = 0
kernel.unprivileged_userns_apparmor_policy = 0
kernel.unprivileged_userns_clone = 0

# about:support settings after sysctl changes
Sandbox
Seccomp-BPF (System Call Filtering)	true
Seccomp Thread Synchronization	true
User Namespaces for privileged processes	true
User Namespaces	false
Content Process Sandboxing	true
Media Plugin Sandboxing	true
Content Process Sandbox Level	4
Effective Content Process Sandbox Level	4

# FF security.sandbox.warn_unprivileged_namespaces is set to true the whole time, no warning on firefox startup in each case

It is to note the Ubuntu kernel features additional userns settings for apparmor than the default Arch kernel (with apparmor enabled), but the FF warning did not appear when deactivating them.

ThoughtBubble · 2024-10-31 02:51:38

seth wrote:

Edit: for clarification, the disabled user NS in the hardened kernel are what causes this warning itfp and re-enabling them will allow FF and other clients to use userspace sandboxing again, but undermine the wider security efforts of the kernel. If you care about overall hardening of the system, you likely just want to click away that dialog.

What exactly are the consequences for not having userspace sandboxing on FF? Also, I want to mention that I am using the regular kernel, not the hardened one.

@loqs, let's continue the conversation about AppArmor and FF from our last thread. The thing is, I'm a newbie and I don't know much about AppArmor. I installed it a while back as I was following the security recommendations on the Arch Wiki, without much thought at that moment. If I set the AA profile for FF to enforce mode and enable user namespace clones, would I have to update the profile every time I get a new update for Firefox? Basically, what I am asking is how much time would it take if I follow your suggestion (for implementing and maintaining)?

Last edited by ThoughtBubble (2024-10-31 02:55:17)

seth · 2024-10-31 06:56:18

https://wiki.mozilla.org/Security/Sandbox
Firefox can't constrain the rights of its child processes, it would have to run as root process for that.
You'd use AppArmor or https://wiki.archlinux.org/title/Firejail for that.

If you seriously want to harden your system, you'll have to read up a lot of stuff (you can start at the wiki)
It's a concept, you setup and pursue a strategy. You cannot just tick some application checkboxes "use the non-l4m3r secure mode lol"

Strike0 · 2024-10-31 10:32:10

@ThoughtBubble, no you don't have to, your potential aa-profile may run for years without issue, but best keep your apparmor learning curve to dedicated threads.

The reason I brought in apparmor was FF commits to accomodate its new release features. I tested on Ubuntu since that enables apparmor per default and is mentioned by FF.

For reference: the FF warning the OP opened this thread about will appear for every Arch FF user who has either disabled userns (be it with hardened-linux or manually via sysctl) or enforces an apparmor profile for it.

Arch Linux

#1 2024-08-31 21:11:53

Some of Firefox's security features may offer less protection on your

#2 2024-09-01 00:26:25

Re: Some of Firefox's security features may offer less protection on your

#3 2024-09-01 08:10:39

Re: Some of Firefox's security features may offer less protection on your

#4 2024-09-01 09:12:49

Re: Some of Firefox's security features may offer less protection on your

#5 2024-09-01 09:14:54

Re: Some of Firefox's security features may offer less protection on your

#6 2024-09-01 14:50:46

Re: Some of Firefox's security features may offer less protection on your

#7 2024-09-01 15:13:53

Re: Some of Firefox's security features may offer less protection on your

#8 2024-09-01 15:19:11

Re: Some of Firefox's security features may offer less protection on your

#9 2024-09-01 15:40:43

Re: Some of Firefox's security features may offer less protection on your

#10 2024-09-01 15:56:50

Re: Some of Firefox's security features may offer less protection on your

#11 2024-09-01 20:16:35

Re: Some of Firefox's security features may offer less protection on your

#12 2024-10-27 23:02:16

Re: Some of Firefox's security features may offer less protection on your

#13 2024-10-28 06:25:21

Re: Some of Firefox's security features may offer less protection on your

#14 2024-10-28 23:23:18

Re: Some of Firefox's security features may offer less protection on your

#15 2024-10-29 00:32:25

Re: Some of Firefox's security features may offer less protection on your

#16 2024-10-29 09:41:33

Re: Some of Firefox's security features may offer less protection on your

#17 2024-10-31 02:51:38

Re: Some of Firefox's security features may offer less protection on your

#18 2024-10-31 06:56:18

Re: Some of Firefox's security features may offer less protection on your

#19 2024-10-31 10:32:10

Re: Some of Firefox's security features may offer less protection on your

Board footer