Notes about security of the Debian GNU/kFreeBSD operating system.
Packages receive timely updates via security.debian.org like any other architecture.
Even if we were a 'development preview' in wheezy, we've issued timely security updates to kfreebsd-9 (9.0) and should continue to do so until 2016-05 (regular wheezy end-of-life). 9.0 isn't supported upstream any more, but stable/9 still is, and we've been able to backport all fixes from there so far.
We lack the resources to participate in a wheezy LTS.
The kfreebsd-8 package does not receive timely security updates. stable/8 upstream EoL is expected 2015-06-30 anyway.
Packages should receive timely updates via security.debian.org; that infrastructure is already set up. Updates for some packages might get delayed if they FTBFS on kfreebsd, openjdk-7 for example.
kfreebsd-10 (10.1) should have upstream support until 2016-12-31. After that we can backport fixes from stable/10. We should be able to support it at least until regular jessie EoL, probably in 2018.
I'm interested in a jessie LTS, but it's too early to make any promises about this yet. We may even consider a "jessie-and-a-half" kernel update to 10.3, if that makes it easier to do this.
FreeBSD didn't implement ASLR until sometime after version 10.1. It will be available in later releases.
Therefore on GNU/kFreeBSD it is not working either. Regardless whether an executable was compiled as PIE, program data is always loaded at a predictable offset. The order of loading shared libraries, the locations they are loaded to, offsets within the stack, and mmap() segments for the heap, always seem to be the same.
OpenBSD can randomise all of those things (see http://www.openbsd.org/papers/ven05-deraadt/index.html).
GNU/Linux wheezy applies ASLR to vary the location of the stack and heap, and the executable's code if it is PIE. But AFAICT it doesn't do the other things. GNU libc's malloc() doesn't seem to impart any further randomness within the heap.
Starting in jessie kfreebsd-10, non-executable stacks are enforced by default. glibc testsuite has already shown it to be working. SELinux supports something similar but it isn't the default in Debian GNU/Linux.
We could see regressions due to this, but upstream FreeBSD thought it was okay to enable it. It did trigger 765070 in the openrc testsuite, and that led to some suspicious code (which did not satisfy W^X principle) being found and fixed; so that's great. It had gone unnoticed on Linux. We may find more issues like this now that our buildds run kfreebsd-10.
DEB_BUILD_HARDENING_STACKPROTECTOR (gcc/g++ -fstack-protector-strong)
This GCC feature works fine on GNU/kFreeBSD just as on GNU/Linux. A random canary is placed on the stack before the return pointer, protecting it from stack buffer overflows.
*** stack smashing detected ***: foo terminated Aborted
DEB_BUILD_HARDENING_RELRO (ld -z relro)
This is just a GNU linker flag, so in Debian packages that enable it for GNU/Linux, it should be enabled on GNU/kFreeBSD too. Confirmed it is working:
$ hardening-check foo foo: Read-only relocations: yes $ objdump -x foo RELRO off 0x0000000000000e10 vaddr 0x0000000000600e10 paddr 0x0000000000600e10 align 2**0 filesz 0x00000000000001f0 memsz 0x00000000000001f0 flags r--
When executed, the RELRO section (second line) is seen to be mapped read-only:
00400000-00401000 r-xp 00003000 00:00 1195251 foo 00600000-00601000 r--p 00003000 00:00 1195251 foo
DEB_BUILD_HARDENING_BINDNOW (ld -z now)
It's possible to enable this on GNU/kFreeBSD as on GNU/Linux. I don't know how to confirm if it is really protecting the GOT section as it should.
$ hardening-check foo relro-now: Read-only relocations: yes $ objdump -x foo BIND_NOW 0x0000000000000000
These are just GCC flags so they work the same on GNU/kFreeBSD as on GNU/Linux.
I think stack protection is not used there yet.
This is enabled in GNU/Linux since jessie, protecting against /tmp races and similar. But not in GNU/kFreeBSD. FreeBSD has some vaguely similar feature, but not enabled by default.