# Hardening Security Options & coredump



## rafael_grether (Nov 24, 2021)

Hello,

It is possible to determine what hardening security option (eg. aslr, aslr_pie, wx, honor_sbrk, ...) causes core dump of a specific application?
$truss don't give details about it, and there is nothing at /var/crash.

The only way is disabling one by one and testing?

Second question, it is possible to avoid this restrictions only for specific application?
An example, Firefox don't like stackgap. But I dont want to set kern.elf64.aslr.stack_gap=0

I read something about elfctl to avoid these restrictions only for a certain applications.
But I dont found a good documentation about this feature.

Thanks,
Grether


----------



## _martin (Nov 26, 2021)

/var/crash is meant for kernel dumps. Some security measures are maybe not that mature yet as you can find in e.g. PR 253208.

Generally if program crashes it creates a core dump in its current working directory named `$name.core` where $name is the name of the process. As a user you have a way of disabling this few ways, also with ulimit (core file size). You can disable it globally with `kern.coredump` sysctl. Setuid binaries don't create dumps due to security restrictions. Can be adjusted with `kern.sugid_coredump`.

If you have such core dump you can inspect it further ; I use gdb(1).

Recently when I helped somebody here _go_ had some issues with W^X. For some reason bash requires it on FreeBSD too (exec stack, really really don't understand why).


----------



## Alain De Vos (Nov 26, 2021)

I had to disable W^X in order to be able to use the ocaml compiler.
Even compiling gcc spits outs errors with W^X.
golang and rclone are known to have problems.
I might be too soon to enable this feature in a general way as it is unknown what will fail.

Next line let firefox work when kern.elf64.aslr.stack_gap=100

```
#elfctl -e +noaslrstkgap /usr/local/bin/firefox
```
ntp & openntpd might have the same issue


----------



## cy@ (Nov 27, 2021)

These stack gap problems have been resolved by a series of commits to14-CURRENT. They haven't been MFCed to 13-STABLE yet.


----------



## Alain De Vos (Nov 27, 2021)

I checked git, there is nothing regarding w^x in the ports ... Weird.
I think some ports by design need writeable and executable pages.
Offcourse nobody dairs to completely rewrite those.


----------



## rafael_grether (Nov 27, 2021)

Is there a list (unofficial) of all packages with problems related a w^x , stackgap or aslr?

And is the problem really with FreeBSD? Or the package vendor who needs to adjust the software to work in accordance with FreeBSD security ELF directives?

I don't know.


----------



## _martin (Nov 27, 2021)

As you can see in the PR I shared this was problem on FreeBSD side.
Personaly I'm not aware of any package list.

You need to check the coredump of the program failing to have more details.


----------



## Alain De Vos (Nov 28, 2021)

In many cases core dump do not provide much information except something went wrong.
In the end i had to disable w^x security feature & aslrstackgap because there were are so many exceptions it was no longer workable.
So currently i have:

```
kern.elf64.aslr.stack_gap=0    # ntp,firefox
kern.elf64.allow_wx=1            # Compilers
```
Until features/bugs got fixed.


----------

