Oh ok, I missed that. So how does this increase security then, if an attacker can just flag the binary safe? Seems like a bit of an honour system.

For the same reason that ASLR improves system security even if you can still in principle pass a special flag to build a non-ASLR binary.

An attacker would have to set such a flag before the binary was loaded, meaning they've already achieved code execution (and syscalls).

This feature is yet another layer of defense against remote exploitation of a currently running program (for example, a web browser). It complements things such as ASLR, stack canaries, the NX bit, ...

How does having a password increase security if an attacker can just run passwd as root and change it?

Hint: having some security and mitigations makes it less likely for an attacker to start with such capabilities.

Disregarding the condescending nature of your comment - I can't find a reference to the actual whitelisting methodology in this article. Several other comments in this thread claim that this is a flag set on ELF section headers, which can be done entirely before the binary is delivered to the system and executed. So in my opinion you need to try harder than this.

If someone can show this is done by configuring the local dynamic linker, so that the end user has full control of the mechanism, then I'm all ears.

If an attacker can ship a malicious binary and run it on the target system, then this defense mechanism is 100% pointless.

It's trying to mitigate exploits, but if your attacker is already running arbitrary code, they don't need those exploits. They're way past that phase.