ASLR and PIE disabled by default

Ben Woolley tautolog at gmail.com
Mon Apr 3 21:34:59 PDT 2017


Hi Carsten,

To be fair, their solution allows you to use pledge for source, and vmm for binary. One issue with binary is not *really* knowing what kind of access it should have, not just for security, but also for functionality. It kinda makes sense. 

Cheers,

Ben

> On Apr 3, 2017, at 6:34 PM, Carsten Mattner <carstenmattner at gmail.com> wrote:
> 
> 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