ASLR and PIE disabled by default
Carsten Mattner
carstenmattner at gmail.com
Mon Apr 3 18:34:51 PDT 2017
There's also the consideration that software we have to be most
careful with is those where we cannot modify the source because we'd
have to patch the binary of a closed source application. This is why I
find it perplexing that OpenBSD just removed their old systrace
AppArmor equivalent.
One thing OpenBSD gets right is marketing. They used to lament the
security implications and uselessness of virtualization only to
implement vmm. They also used to be vocal about clang not being a
viable choice but in light of other alternatives for AARCH64 are on
their way of incorporating it into base. I'm not saying this to
complain about OpenBSD but merely to make the point that investing in
pledge(2) is a hard sell to me personally given their track record. It
doesn't confine binaries and I have a feeling they might replace it in
4 years, so I'm wary of carrying an #ifdef path in my own code.
With their great marketing, everybody talks about LibreSSL or
pledge(2). Projects can learn from their PR tactics. Capsicum
exists for Linux, FreeBSD, DragonflyBSD, so I'm more open to
the idea of accepting a patch from the FreeBSD ports tree upstream
in my projects' main branches.
If I had to guess I'd say they will reimplement something like
firejail/systrace as an extension of pledge that doesn't require
patching the source and then use it as an opt-out mechanism where
you have to whitelist your favorite personal application to have free
reign over the machine. Whatever you do, you will inevitably run
into the same design considerations that are well travelled and
can be inspected in SELinux and more radical capability based
kernels. I am of the opinion that security can only work
reasonably if mechanisms are opt-out like grsecurity's
flag to allow JIT binaries. This allows monitoring as well
as knowing your likely open doors for intruders.
More information about the Users
mailing list