[GH-ISSUE #2689] [Feature request] Integrate hardened_malloc When Available on System

gitea-mirror commented

2026-05-05 08:20:46 -06:00

Owner

Originally created by @ilikenwf on GitHub (May 10, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2689

I've tested it already with many applications and so far found it to not impact performance or break things so far. Having a flag within firejail configs to enable hardened_malloc would add another level of security, in my opinion.

While it was originally written with Android in mind, it has since been made generic and works well under Linux. I have it working already under Arch: https://aur.archlinux.org/packages/hardened-malloc-git/

Hardened_Malloc:

https://github.com/GrapheneOS/hardened_malloc

While it would perform better and otherwise integrate better if integrated into libc, I doubt that such an integration would be easy at this juncture in most distros.

Originally created by @ilikenwf on GitHub (May 10, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2689 I've tested it already with many applications and so far found it to not impact performance or break things so far. Having a flag within firejail configs to enable hardened_malloc would add another level of security, in my opinion. While it was originally written with Android in mind, it has since been made generic and works well under Linux. I have it working already under Arch: https://aur.archlinux.org/packages/hardened-malloc-git/ **Hardened_Malloc:** https://github.com/GrapheneOS/hardened_malloc While it would perform better and otherwise integrate better if integrated into libc, I doubt that such an integration would be easy at this juncture in most distros.

gitea-mirror

2026-05-05 08:20:46 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:20:48 -06:00

Author

Owner

@ilikenwf commented on GitHub (May 10, 2019):

I do recognize that using

firejail --env=LD_PRELOAD='/usr/lib/libhardened_malloc.so' /path/to/binary

Will work, but seeing as this is a security feature I wonder about the feasibility of integration somehow.

@ilikenwf commented on GitHub (May 10, 2019): I do recognize that using ```firejail --env=LD_PRELOAD='/usr/lib/libhardened_malloc.so' /path/to/binary``` Will work, but seeing as this is a security feature I wonder about the feasibility of integration somehow.

gitea-mirror commented

2026-05-05 08:20:50 -06:00

Author

Owner

@ilikenwf commented on GitHub (May 10, 2019):

...it does seem to break "man" for some reason. Setting MAN_DISABLE_SECCOMP=1 fixes that. I don't run man in a firejail but was playing with this lib system wide.

@ilikenwf commented on GitHub (May 10, 2019): ...it does seem to break "man" for some reason. Setting MAN_DISABLE_SECCOMP=1 fixes that. I don't run man in a firejail but was playing with this lib system wide.

gitea-mirror commented

2026-05-05 08:20:51 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 11, 2019):

I believe this is rather beyond of firejail scope which is to create sandbox, not to fiddle with apps behavior under the hood. Moreover there will be very few users who will have hardened_malloc installed on their systems thus integraion value is quite small. Nevertheless using hardened_malloc is nice idea and I think LD_PRELOAD trick you posted is sufficient.

@Vincent43 commented on GitHub (May 11, 2019): I believe this is rather beyond of firejail scope which is to create sandbox, not to fiddle with apps behavior under the hood. Moreover there will be very few users who will have hardened_malloc installed on their systems thus integraion value is quite small. Nevertheless using hardened_malloc is nice idea and I think LD_PRELOAD trick you posted is sufficient.

gitea-mirror commented

2026-05-05 08:20:52 -06:00

Author

Owner

@openffchrome commented on GitHub (May 18, 2019):

hey, firejail --env=LD_PRELOAD='/usr/lib/libhardened_malloc.so' --x11=xephyr --profile=/home/me/.config/firejail/firefox.profile openbox --startup firefox

is this the correct way to use hardened_malloc for firejailed Firefox with Xephyr and Openbox on arch? or it will be used for xephyr/openbox instead of firefox? i don't get it

thx

@openffchrome commented on GitHub (May 18, 2019): hey, `firejail --env=LD_PRELOAD='/usr/lib/libhardened_malloc.so' --x11=xephyr --profile=/home/me/.config/firejail/firefox.profile openbox --startup firefox` is this the correct way to use hardened_malloc for firejailed Firefox with Xephyr and Openbox on arch? or it will be used for xephyr/openbox instead of firefox? i don't get it thx

gitea-mirror commented

2026-05-05 08:20:53 -06:00

Author

Owner

@ilikenwf commented on GitHub (May 18, 2019):

Try it and check lsof to see if the firefox process is using the libhardened_malloc.so file...

@netblue30 to be more generic in my request, perhaps an option to allow LD_PRELOAD in the .profile files, if it's owned by root or lives in the /etc/firejail path, but not in the custom user ~/.config/firejail path? That would at least ensure that preloading is only allowed when root wants it to be.

@ilikenwf commented on GitHub (May 18, 2019): Try it and check lsof to see if the firefox process is using the libhardened_malloc.so file... @netblue30 to be more generic in my request, perhaps an option to allow LD_PRELOAD in the .profile files, if it's owned by root or lives in the /etc/firejail path, but not in the custom user ~/.config/firejail path? That would at least ensure that preloading is only allowed when root wants it to be.

gitea-mirror commented

2026-05-05 08:20:54 -06:00

Author

Owner

@openffchrome commented on GitHub (May 18, 2019):

ho ok, it's working fine, thanks!

@openffchrome commented on GitHub (May 18, 2019): ho ok, it's working fine, thanks!

gitea-mirror commented

2026-05-05 08:20:55 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 20, 2019):

to be more generic in my request, perhaps an option to allow LD_PRELOAD in the .profile files, if it's owned by root or lives in the /etc/firejail path, but not in the custom user ~/.config/firejail path? That would at least ensure that preloading is only allowed when root wants it to be.

We don't differentiate between root owned and user owned profiles because it wouldn't make sense when user can pass any profile option manually firejail --foo --profile=xxx. We could make a on/off switch in firejail.config but isn't passing LD_PRELOAD as env variable easier and more user friendly?

@Vincent43 commented on GitHub (May 20, 2019): > to be more generic in my request, perhaps an option to allow LD_PRELOAD in the .profile files, if it's owned by root or lives in the /etc/firejail path, but not in the custom user ~/.config/firejail path? That would at least ensure that preloading is only allowed when root wants it to be. We don't differentiate between root owned and user owned profiles because it wouldn't make sense when user can pass any profile option manually `firejail --foo --profile=xxx`. We could make a on/off switch in `firejail.config` but isn't passing LD_PRELOAD as env variable easier and more user friendly?

gitea-mirror commented

2026-05-05 08:20:56 -06:00

Author

Owner

@ghost commented on GitHub (May 20, 2019):

Maybe add a new disable-hardened_malloc.inc (or any other suitable name) containing blacklist /usr/lib/libhardened_malloc*, so this can be integrated nicely like all other stuff via:

...
# Allow hardened_malloc
env LD_PRELOAD=/usr/lib/libhardened_malloc.so
noblacklist /usr/lib/libhardened_malloc*
# whitelist /usr/lib/libhardened_malloc* - for a whitelist profile
...
include disable-hardened_malloc.inc
...
# private-lib ...,libhardened_malloc*,... - for profiles using private-lib

@ghost commented on GitHub (May 20, 2019): Maybe add a new `disable-hardened_malloc.inc` (or any other suitable name) containing `blacklist /usr/lib/libhardened_malloc*`, so this can be integrated nicely like all other stuff via: ``` ... # Allow hardened_malloc env LD_PRELOAD=/usr/lib/libhardened_malloc.so noblacklist /usr/lib/libhardened_malloc* # whitelist /usr/lib/libhardened_malloc* - for a whitelist profile ... include disable-hardened_malloc.inc ... # private-lib ...,libhardened_malloc*,... - for profiles using private-lib ```

gitea-mirror commented

2026-05-05 08:20:58 -06:00

Author

Owner

@Vincent43 commented on GitHub (May 20, 2019):

But hardened-malloc is supposed to increase security, what's the point of blackisting it?

@Vincent43 commented on GitHub (May 20, 2019): But hardened-malloc is supposed to increase security, what's the point of blackisting it?

gitea-mirror commented

2026-05-05 08:20:59 -06:00

Author

Owner

@ghost commented on GitHub (May 20, 2019):

@Vincent43 Using env LD_PRELOAD=/usr/lib/libhardened_malloc.so on a system where hardened_malloc isn't available would break firejail profiles. That's why I suggested the above format, so users can enable it not only via the CLI but also inside profile files.

Update: all this is assuming hardened_malloc is NOT already enabled system-wide.

@ghost commented on GitHub (May 20, 2019): @Vincent43 Using `env LD_PRELOAD=/usr/lib/libhardened_malloc.so` on a system where hardened_malloc isn't available would break firejail profiles. That's why I suggested the above format, so users can enable it not only via the CLI but also inside profile files. Update: all this is assuming hardened_malloc is *NOT* already enabled system-wide.

gitea-mirror commented

2026-05-05 08:21:00 -06:00

Author

Owner

@Vincent43 commented on GitHub (Aug 11, 2019):

@ilikenwf ~~FYI from my brief testing it seems that LD_PRELOAD trick is incompatible with noroot option.~~

@Vincent43 commented on GitHub (Aug 11, 2019): @ilikenwf ~~FYI from my brief testing it seems that `LD_PRELOAD` trick is incompatible with `noroot` option.~~

gitea-mirror commented

2026-05-05 08:21:01 -06:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2019):

@Vincent43 I'm using the LD_PRELOAD trick as described in my earlier comment for several months now on a selection of profiles which happen to have the noroot option. Haven't experienced anything out of the ordinary yet and I'm regularly double-checking via lsof if things work as expected. In that context I'm eager to learn what you mean with incompatible exactly. Can you elaborate on your findings if you find the time?

@ghost commented on GitHub (Aug 12, 2019): @Vincent43 I'm using the LD_PRELOAD trick as described in my earlier comment for several months now on a selection of profiles which happen to have the `noroot` option. Haven't experienced anything out of the ordinary yet and I'm regularly double-checking via lsof if things work as expected. In that context I'm eager to learn what you mean with `incompatible` exactly. Can you elaborate on your findings if you find the time?

gitea-mirror commented

2026-05-05 08:21:02 -06:00

Author

Owner

@Vincent43 commented on GitHub (Aug 12, 2019):

@glitsj16 I thought it doesn't work with noroot because lsof didn't show hardened-malloc usage but it seems that running lsof as root shows it. Sorry for the confusion.

@Vincent43 commented on GitHub (Aug 12, 2019): @glitsj16 I thought it doesn't work with `noroot` because `lsof` didn't show hardened-malloc usage but it seems that running `lsof` as root shows it. Sorry for the confusion.

gitea-mirror commented

2026-05-05 08:21:03 -06:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2019):

@Vincent43 That caught me too early on, thanks for clearing things up.

For prosperity's sake, here's a command that shows a sorted list of processes using hardened-malloc:

$ sudo lsof -w +c 0 /usr/lib/libhardened_malloc.so | awk '{print $1}' | sort

@ghost commented on GitHub (Aug 12, 2019): @Vincent43 That caught me too early on, thanks for clearing things up. For prosperity's sake, here's a command that shows a sorted list of processes using hardened-malloc: `$ sudo lsof -w +c 0 /usr/lib/libhardened_malloc.so | awk '{print $1}' | sort`

gitea-mirror commented

2026-05-05 08:21:04 -06:00

Author

Owner

@Vincent43 commented on GitHub (Sep 29, 2019):

Closing as there is nothing to do here for firejail. Keep in mind that upstream recommends to enable hardened_malloc system-wide by adding it to /etc/ld.so.preload.

Using env LD_PRELOAD is meant only for testing:

Using the LD_PRELOAD environment variable to load it on a case-by-case basis will not work when AT_SECURE is set such as with setuid binaries. It's also generally not a recommended approach for production usage. The recommendation is to enable it globally and make exceptions for performance critical cases by running the application in a container / namespace without it enabled.

@Vincent43 commented on GitHub (Sep 29, 2019): Closing as there is nothing to do here for firejail. Keep in mind that upstream recommends to enable hardened_malloc system-wide by [adding it to /etc/ld.so.preload](https://github.com/GrapheneOS/hardened_malloc#traditional-linux-based-operating-systems). Using `env LD_PRELOAD` is meant only for testing: > Using the LD_PRELOAD environment variable to load it on a case-by-case basis will not work when AT_SECURE is set such as with setuid binaries. It's also generally not a recommended approach for production usage. The recommendation is to enable it globally and make exceptions for performance critical cases by running the application in a container / namespace without it enabled.

gitea-mirror commented

2026-05-05 08:21:04 -06:00

Author

Owner

@sempervictus commented on GitHub (Oct 14, 2019):

@Vincent43: i think that what @glitsj16 proposed is quite rational, does not break backwards compatibility, and does permit jailed programs to run with the hardened allocator when invoked via the symlinks in /usr/local/bin as opposed to their actual binpaths (this is how Arch handles it anyway).
Jails are intended to provide isolation from the rest of the system - in Linux these concepts are constructed from namespaces, but there's no such thing as a memory allocator namespace unless you overlay a filesystem with a different allocator compiled into the libc (but ABI compatible as a thin shim). Allowing users to change a single config line, or possibly a couple if they need to re-blacklist it for some apps, once, makes "security easy" and therefore more likely to be implemented.
The /etc/ld.so.preload method is a breaking change - @thestinger can explain what works and what doesnt right now, but there are userspace libraries which do have performance or compatibility issues with it. There are very few, but they exist. i use the allocator quite a bit, its great for phones and for Linux servers (both with linux-hardened or grsec kernels), but it can break with qt apps and the like... so for now it needs to be opt-in, and the approach proposed by @glitsj16 permits doing so easily and in line with current documentation for using firejail.
Any chance of reopening this and taking up the enhancement?

@sempervictus commented on GitHub (Oct 14, 2019): @Vincent43: i think that what @glitsj16 proposed is quite rational, does not break backwards compatibility, and does permit _jailed_ programs to run with the hardened allocator when invoked via the symlinks in /usr/local/bin as opposed to their actual binpaths (this is how Arch handles it anyway). Jails are intended to provide isolation from the rest of the system - in Linux these concepts are constructed from namespaces, but there's no such thing as a memory allocator namespace unless you overlay a filesystem with a different allocator compiled into the libc (but ABI compatible as a thin shim). Allowing users to change a single config line, or possibly a couple if they need to re-blacklist it for some apps, once, makes "security easy" and therefore more likely to be implemented. The /etc/ld.so.preload method is a breaking change - @thestinger can explain what works and what doesnt right now, but there are userspace libraries which do have performance or compatibility issues with it. There are very few, but they exist. i use the allocator quite a bit, its great for phones and for Linux servers (both with linux-hardened or grsec kernels), but it can break with qt apps and the like... so for now it needs to be opt-in, and the approach proposed by @glitsj16 permits doing so easily and in line with current documentation for using firejail. Any chance of reopening this and taking up the enhancement?

gitea-mirror commented

2026-05-05 08:21:06 -06:00

Author

Owner

@Vincent43 commented on GitHub (Oct 14, 2019):

@sempervictus you are free to add env LD_PRELOAD=/usr/lib/libhardened_malloc.so to <app>. local or globals.local or wherever you like. You don't need fiejail assistance for that. hardend_malloc and firejail are completely orthogonal and I don't see benefit of binding them together if using both is such trivial as shown above.

@Vincent43 commented on GitHub (Oct 14, 2019): @sempervictus you are free to add `env LD_PRELOAD=/usr/lib/libhardened_malloc.so` to `<app>. local` or `globals.local` or wherever you like. You don't need fiejail assistance for that. hardend_malloc and firejail are completely orthogonal and I don't see benefit of binding them together if using both is such trivial as shown above.

gitea-mirror commented

2026-05-05 08:21:07 -06:00

Author

Owner

@Vincent43 commented on GitHub (Oct 14, 2019):

The fact that upstream doesn't recommend using LD_PRELOAD env is strong argument against officially including that somewhere in firejail as pretending to support things which are not supported by upstream would be dishonest.

@Vincent43 commented on GitHub (Oct 14, 2019): The fact that upstream doesn't recommend using `LD_PRELOAD` env is strong argument against officially including that somewhere in firejail as pretending to support things which are not supported by upstream would be dishonest.

gitea-mirror commented

2026-05-05 08:21:07 -06:00

Author

Owner

@ilikenwf commented on GitHub (Oct 14, 2019):

I also have noticed occasional instability in some applications, so
including it somewhere in firejail is a bad idea.

On 10/14/19 8:38 AM, Vincent43 wrote:

The fact that upstream doesn't recommend using |LD_PRELOAD| env is
strong argument against officially including that somewhere in
firejail as pretending to support things which are not supported by
upstream would be dishonest.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/netblue30/firejail/issues/2689?email_source=notifications&email_token=AADFIORE3YZZT4HBMPDBJ4TQORY43A5CNFSM4HMESMHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBEW2CY#issuecomment-541682955,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADFIOU5VVPOB3IFL5G5KDTQORY43ANCNFSM4HMESMHA.

@ilikenwf commented on GitHub (Oct 14, 2019): I also have noticed occasional instability in some applications, so including it somewhere in firejail is a bad idea. On 10/14/19 8:38 AM, Vincent43 wrote: > > The fact that upstream doesn't recommend using |LD_PRELOAD| env is > strong argument against officially including that somewhere in > firejail as pretending to support things which are not supported by > upstream would be dishonest. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/netblue30/firejail/issues/2689?email_source=notifications&email_token=AADFIORE3YZZT4HBMPDBJ4TQORY43A5CNFSM4HMESMHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBEW2CY#issuecomment-541682955>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADFIOU5VVPOB3IFL5G5KDTQORY43ANCNFSM4HMESMHA>. >

gitea-mirror commented

2026-05-05 08:21:09 -06:00

Author

Owner

@thestinger commented on GitHub (Oct 14, 2019):

@ilikenwf Lots of applications and libraries have latent memory corruption bugs and they don't play well with a memory allocator designed to be hostile to memory corruption. That's the whole point of the hardened_malloc project. I recommend reading through https://github.com/GrapheneOS/hardened_malloc/blob/master/README.md and not using it without having an understanding of what it does and a willingness to triage bugs that it uncovers. You're making it sound like this is a problem with hardened_malloc when it's the point of the project. It's not a positive thing that the standard memory allocators in glibc, Bionic and musl are so friendly to memory corruption and exploitation.

I've had to put a lot of work into addressing latent memory corruption bugs to have it deployed in GrapheneOS for the entire OS. AOSP is already tested with ASan and other sanitizers upstream as a whole and yet there are still bugs that either slip through or don't get treated as blockers for releases. Most projects don't have the same level of testing and usage of sanitizers, so there are more latent memory corruption bugs triggered during regular use.

@thestinger commented on GitHub (Oct 14, 2019): @ilikenwf Lots of applications and libraries have latent memory corruption bugs and they don't play well with a memory allocator designed to be hostile to memory corruption. That's the whole point of the hardened_malloc project. I recommend reading through https://github.com/GrapheneOS/hardened_malloc/blob/master/README.md and not using it without having an understanding of what it does and a willingness to triage bugs that it uncovers. You're making it sound like this is a problem with hardened_malloc when it's the point of the project. It's not a positive thing that the standard memory allocators in glibc, Bionic and musl are so friendly to memory corruption and exploitation. I've had to put a lot of work into addressing latent memory corruption bugs to have it deployed in GrapheneOS for the entire OS. AOSP is already tested with ASan and other sanitizers upstream as a whole and yet there are still bugs that either slip through or don't get treated as blockers for releases. Most projects don't have the same level of testing and usage of sanitizers, so there are more latent memory corruption bugs triggered during regular use.

gitea-mirror commented

2026-05-05 08:21:09 -06:00

Author

Owner

@thestinger commented on GitHub (Oct 14, 2019):

@Vincent43 One issue with using LD_PRELOAD is that it won't work if AT_SECURE is set. The AT_SECURE flag is a bit subtle since it can be set in more cases than setuid/setgid such as capabilities or an LSM. In the past (which is still relevant on many systems due to LTS kernel branches), it was set when transitioning into alternate SELinux MAC domains, such as when entering a sandbox. It's more reliable to use the global configuration file, which works when AT_SECURE, but even then, that's not my preferred approach. In a hardened system, it's not possible to modify that kind of configuration after building due to full verified boot for the OS anyway...

It's best to integrate hardened_malloc into libc so it works globally without needing configuration and can't run into edge cases involving glibc bugs. Officially, glibc supports malloc substitution via the preloading approach, but dynamic linking is complicated and there are edge cases where it may not work properly. For that reason, jemalloc has traditionally used the malloc hooks as a fallback approach to deal with glibc not fully supporting substitution via preloading in all cases. That's rarely an issue, since it only comes up in obscure edge cases, but it's still a problem. So, preloading mostly works, and is officially supported by glibc, but I don't have much confidence in their implementation and I think it has known bugs. It's not a security issue, but it's a potential compatibility issue.

Additionally, there's a lot of other hardening that should really be done in libc alongside using a hardened malloc implementation. For glibc in particular, the _FORTIFY_SOURCE implementation is lackluster. It doesn't cover buffer reads and lacks Clang support, both of which are part of the Bionic implementation. There's also a lack of support for production usage of CFI and SafeStack/ShadowCallStack (ShadowCallStack is currently only for arm64 due to it being harder to do correctly on x86), along with a mix of missing and lackluster protection for internal function pointers and other sensitive data. The region-based approach in hardened_malloc also makes sense more broadly, as do randomized guard regions, and libc is where most of those changes need to be integrated. There are a lot of other both minor and major changes that should be done in libc to make it into a hardened libc. I think it would be a lot easier to start from musl rather than glibc too. For Bionic, a lot of these things are in a much better state upstream, and I've done a lot of work on reporting issues, upstreaming changes and implementing enhancements downstream. I'm currently working on restoring past libc hardening work for it, which I need to port to the current release. It would be great if someone did comparable work for musl.

@thestinger commented on GitHub (Oct 14, 2019): @Vincent43 One issue with using LD_PRELOAD is that it won't work if AT_SECURE is set. The AT_SECURE flag is a bit subtle since it can be set in more cases than setuid/setgid such as capabilities or an LSM. In the past (which is still relevant on many systems due to LTS kernel branches), it was set when transitioning into alternate SELinux MAC domains, such as when entering a sandbox. It's more reliable to use the global configuration file, which works when AT_SECURE, but even then, that's not my preferred approach. In a hardened system, it's not possible to modify that kind of configuration after building due to full verified boot for the OS anyway... It's best to integrate hardened_malloc into libc so it works globally without needing configuration and can't run into edge cases involving glibc bugs. Officially, glibc supports malloc substitution via the preloading approach, but dynamic linking is complicated and there are edge cases where it may not work properly. For that reason, jemalloc has traditionally used the malloc hooks as a fallback approach to deal with glibc not fully supporting substitution via preloading in all cases. That's rarely an issue, since it only comes up in obscure edge cases, but it's still a problem. So, preloading mostly works, and is officially supported by glibc, but I don't have much confidence in their implementation and I think it has known bugs. It's not a security issue, but it's a potential compatibility issue. Additionally, there's a lot of other hardening that should really be done in libc alongside using a hardened malloc implementation. For glibc in particular, the _FORTIFY_SOURCE implementation is lackluster. It doesn't cover buffer reads and lacks Clang support, both of which are part of the Bionic implementation. There's also a lack of support for production usage of CFI and SafeStack/ShadowCallStack (ShadowCallStack is currently only for arm64 due to it being harder to do correctly on x86), along with a mix of missing and lackluster protection for internal function pointers and other sensitive data. The region-based approach in hardened_malloc also makes sense more broadly, as do randomized guard regions, and libc is where most of those changes need to be integrated. There are a lot of other both minor and major changes that should be done in libc to make it into a hardened libc. I think it would be a lot easier to start from musl rather than glibc too. For Bionic, a lot of these things are in a much better state upstream, and I've done a lot of work on reporting issues, upstreaming changes and implementing enhancements downstream. I'm currently working on restoring past libc hardening work for it, which I need to port to the current release. It would be great if someone did comparable work for musl.

gitea-mirror commented

2026-05-05 08:21:10 -06:00

Author

Owner

@ilikenwf commented on GitHub (Oct 14, 2019):

I was saying what I said because many casual users also use firejail, and so I just think defaulting to using hardened_malloc may be a mistake since they aren't capable of tracing said bugs.

Likewise, some applications also already have their own malloc implementations, which can sometimes appear to have issues with corruption as you mentioned, but I find it hard to determine whether or not this is the case when dealing with something like Mozilla...

Apologies for being vague and unclear, including it in firejail is one thing, defaulting it to "on" within firejail is another.

@ilikenwf commented on GitHub (Oct 14, 2019): I was saying what I said because many casual users also use firejail, and so I just think defaulting to using hardened_malloc may be a mistake since they aren't capable of tracing said bugs. Likewise, some applications also already have their own malloc implementations, which can sometimes appear to have issues with corruption as you mentioned, but I find it hard to determine whether or not this is the case when dealing with something like Mozilla... Apologies for being vague and unclear, including it in firejail is one thing, defaulting it to "on" within firejail is another.

Rows
Columns

[GH-ISSUE #2689] [Feature request] Integrate hardened_malloc When Available on System #1694