Firefox binary not executable

[boredsquirrel]

Are changes to make everything but path unexecutable already in place?

I cannot run the firefox binary in a nonpath directory. Would be good to have it documented how to make a directory executable, if this is the case.

secureblue kinoite-main-laptop-userns-hardened

Trying to run the latest firefox binary from /var/home/user/Programs/firefox/firefox

[RoyalOughtness]

Yeah, firefox has known compatibility issues with hardened_malloc: https://github.com/GrapheneOS/hardened_malloc/issues/123

[RoyalOughtness]

Oh, I may have misread your comment. What do you mean by not executable? Just set it as executable if it's missing the executable bit.

[boredsquirrel]

Weird, the Flatpak works normally.

It does not start. I set it as executable, alias it in fish/bash, run it from desktop file. I even moved it (and torbrowser) to ~/.local/bin/Browsers but that didnt change anything.

But yes I can imagine the Flatpak somehow doesnt use the hardened malloc, despite the settings.

I didnt exit yafti and also reinstalled all the flatpaks as user flatpaks.

[RoyalOughtness]

Weird, the Flatpak works normally.

It does not start. I set it as executable, alias it in fish/bash, run it from desktop file. I even moved it (and torbrowser) to ~/.local/bin/Browsers but that didnt change anything.

But yes I can imagine the Flatpak somehow doesnt use the hardened malloc, despite the settings.

I didnt exit yafti and also reinstalled all the flatpaks as user flatpaks.

what happens when you run the binary from the terminal? The location of the binary should have no effect on whether it's executable, so there's no point moving it around.

[boredsquirrel]

Okay makes sense so its just the malloc. It failed pretty early and gave some malloc error output.

Upstream issue, weirdly on GrapheneOS Firefox works fine. The Flatpak does start but performs horribly.

[RoyalOughtness]

Okay makes sense so its just the malloc. It failed pretty early and gave some malloc error output.

Upstream issue, weirdly on GrapheneOS Firefox works fine. The Flatpak does start but performs horribly.

Yeah, Android Firefox and desktop linux Firefox are pretty different

[34N0]

I have trouble running the TOR browser on Secureblue. This might be related. I'll try running it without hardened malloc.

[boredsquirrel]

I read somewhere that you can compile Firefox with --disable-jemalloc flag. I suppose this makes it use hardened_malloc instead?

Not sure what the outcome of this issue about --enable-hardening flag was.

I know that currently only Chromium is supported, but it would be nice to investigate it further. Especially with bubblejail, Torbrowser may be best for certain use cases.

[boredsquirrel]

Update: with Mozillas documentation I just compiled Firefox with that flag --disable-jemalloc. It starts up well inside a F39 Distrobox and on the host system. The same can be done with Thunderbird and Torbrowser.

# dependencies, in a F39 Distrobox
sudo dnf install -y rust cargo gcc python3 m4 git

cd ~
mkdir Firefox-Build && cd Firefox-Build

# clone with Git because Mercurial is weird
curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py -O
python3 ./bootstrap.py --vcs=git

Configurations are stored in mozconfig in the mozilla-unified directory:

# run this to include this config
# export MOZCONFIG=./mozconfig
# ./mach build

# include the common mozconfig (not existing?)
# . ./mozconfig-common

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox
mk_add_options MOZ_PARALLEL_BUILD=8 #build with 8 threads!

# put all arguments here
ac_add_options --enable-optimize --disable-jemalloc --enable-project=browser
# --enable-default-toolkit=cairo-gtk3-wayland-only # this may compile with Wayland only, which would be very useful

# firefox (this uses git release i.e. Nightly, has cool stuff like JXL)
# mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox
# ac_add_options --enable-project=browser

# thunderbird
# mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-thunderbird
# ac_add_options --enable-project=comm/mail

# torbrowser would use ESR

build

export MOZCONFIG=./mozconfig && ./mach build

I have no idea what I am doing to be honest, but I built Nightly and ran some tests

• Thorium WebGL demos
• Web Basemark (FF (without any configs) average: 403,19, Chromium (with Policies) average: 584,875), extreme lag on Canvas

I am not sure if it uses hardened_malloc but it should? Everything runs perfectly fine, not a single crash or occurrence.

I also tried manually doing LD_PRELOAD=/var/run/host/usr/lib64/libhardened_malloc.so before executing the binary with mach.

Missing:

• SELinux policy
• bubblejail integration
• KDE theme
• desktop entry (icon etc.)

[RoyalOughtness]

@trytomakeyouprivate you can check if it's using hardened_malloc using this: https://github.com/GrapheneOS/hardened_malloc/issues/134#issuecomment-797147616

[boredsquirrel]

Looks good!

> ps a | grep firefox
 12546 pts/5    Sl+    0:14 ./firefox
> grep libhardened_malloc.so /proc/12546/maps                                                                                                                               ✘ 1
7f8ab68e2000-7f8ab68e4000 r--p 00000000 00:1e 1509465                    /usr/lib64/libhardened_malloc.so
7f8ab68e4000-7f8ab68e9000 r-xp 00002000 00:1e 1509465                    /usr/lib64/libhardened_malloc.so
7f8ab68e9000-7f8ab68eb000 r--p 00007000 00:1e 1509465                    /usr/lib64/libhardened_malloc.so
7f8ab68eb000-7f8ab68ec000 r--p 00008000 00:1e 1509465                    /usr/lib64/libhardened_malloc.so
7f8ab68ec000-7f8ab68ed000 rw-p 00009000 00:1e 1509465                    /usr/lib64/libhardened_malloc.so

Firefox creates multiple processes and every single one of them looks like this!

---

I created a Librewolf issue about supplying versions with jemalloc disabled. There is a chance, but not clear. Upstream Fedora Firefox could enable ac_add_options --enable-replace-malloc according to this post, which would make it automatically choose hardened_malloc.

Another option would be to build Firefox, Firefox ESR and from that Torbrowser and Thunderbird with the matching parameters, possibly even more like the Mercury browser mozconfigs and policies to debloat a bit.

[boredsquirrel]

https://bugzilla.redhat.com/show_bug.cgi?id=2262277

Fedora Firefox should now automatically use hardened_malloc in Secureblue!

Now I need to ask, is secureblue based off an image that has added Firefox? I thought ublue main had no Firefox included? Best would be to not have Firefox installed and not needing to override-remove it, so it can be installed from Fedora. As upstream seems to not want to add that compile flag by default.

[RoyalOughtness]

For starters, it frankly makes no sense to me why this issue even exists. If you intend to use Firefox, it's clear that security isn't a priority for you. So with that in mind, why are you using secureblue to begin with? Doesn't make sense.

https://bugzilla.redhat.com/show_bug.cgi?id=2262277 Fedora Firefox should now automatically use hardened_malloc in Secureblue!

Why do you say that? The bug you reported is brand new and hasn't even be acknowledged. How does this affect secureblue at all?

As a sidenote, stop referencing secureblue in upstream reports. They are under no obligation to support secureblue as a use case. Please do not use "it doesn't work on secureblue" as a rationale in upstream reports as it reflects badly on the project.

Now I need to ask, is secureblue based off an image that has added Firefox? I thought ublue main had no Firefox included?

Firefox is default in upstream Fedora images. uBlue doesn't remove it. We remove it. https://github.com/secureblue/secureblue/blob/live/config/common/remove-firefox.yml

Best would be to not have Firefox installed and not needing to override-remove it

I have no clue what this means. We remove it and that's intentional.

As upstream seems to not want to add that compile flag by default.

Which is entirely understandable since they're under no obligation to cater to this use case.

[boredsquirrel]

Secureblue is way more than using Chromium lol. Firefox is secure depending on your threat model, and I just highly prefer it for many reasons (sync, addon support, cookie containers, not pinging Google on every damn action)

I now build it myself with removed jemalloc and it works just fine using hardened_malloc.

So please stop accusing me of not giving a f**k if I dont want to use a Google Browser. Firefox has many parts of the code rewritten in rust which is critical, and I am in the process of sandboxing the entire browser using Bubblejail.

the bug was a duplicate of this one

Please do not use "it doesn't work on secureblue" as a rationale in upstream reports as it reflects badly on the project.

That makes sense, and I will only reference it in the "steps to reproduce" as secureblue is the way to reproduce. But yes, I understand that this may give a bad reputation.

So well, Firefox on Fedora should now allow replacing the malloc.

I will not ask to not remove it, even though it could be possible to just replace the desktop entry to effectively neuter it.

The best solution would be that upstream does not include it, due to this bug which caused my strange phrasing above (an override remove blocks an install).

This is the upstream issue about removing Firefox from the images but it is entirely about "does the Flatpak work yet".

[boredsquirrel]

So, if I opened a PR removing the "remove firefox" and placing an empty file in /usr/share/applications/firefox.desktop, would that be immediately closed?

[RoyalOughtness]

Secureblue is way more than using Chromium lol So please stop accusing me of not giving a f**k if I dont want to use a Google Browser.

I didn't make any accusations. I made a simple logical deduction:

1. The browser is the largest amount of attack surface area for the overwhelming majority of desktop use cases.
2. Prioritizing security means prioritizing securing the largest attack surfaces.
3. Not using the most secure option for the largest attack surface implies a lack of prioritization of security generally.

Firefox is secure depending on your threat model

Not relative to chromium.

and I just highly prefer it for many reasons

That's fine, you can use any browser you wish.

[RoyalOughtness]

So, if I opened a PR removing the "remove firefox" and placing an empty file in /usr/share/applications/firefox.desktop, would that be immediately closed?

Correct, as it's not in scope for secureblue nor is firefox support in scope. You have numerous ways to get firefox installed. Nix. Flatpak. etc.

You are (again) continuing to focus on what's best for you and your individual use case regardless of what's in the goals for the project and community. I am again issuing a formal warning and will not be as lenient this time around.