Hardening Security Options & coredump

rafael_grether

rafael_grether

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
 
/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).
 
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
Code: 
#elfctl -e +noaslrstkgap /usr/local/bin/firefox
ntp & openntpd might have the same issue
 
These stack gap problems have been resolved by a series of commits to14-CURRENT. They haven't been MFCed to 13-STABLE yet.
 
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.
 
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.
 
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.
 
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:
Code: 
kern.elf64.aslr.stack_gap=0    # ntp,firefox
kern.elf64.allow_wx=1            # Compilers
Until features/bugs got fixed.
 
You must log in or register to reply here.
Back
Top