Peres: Wayland Compositors - Why and How to Handle Privileged Clients!

Posted Feb 28, 2014 6:24 UTC (Fri) by deepfire (guest, #26138)
In reply to: Peres: Wayland Compositors - Why and How to Handle Privileged Clients! by mathstuf
Parent article: Peres: Wayland Compositors - Why and How to Handle Privileged Clients!

So it's basically un-administrable, as a build-time issue.

Were it an ELF flag, you could toggle it in-place, but in-place symbol attribute modification is far less practical.

LD_PRELOAD is a fairly common attack vector, and nothing is being done about it.

to post comments

Peres: Wayland Compositors - Why and How to Handle Privileged Clients!

Posted Feb 28, 2014 6:48 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

How many flags would you require? One for ptrace, another for LD_PRELOAD, another for tomorrow's mechanism? One flag seems overbroad. Maybe on your secure machines, you should use a linker which doesn't support LD_PRELOAD?

I've been considering using protected in my projects since they're C++ and that anything done is likely to break in amazing ways (How do you fix up vtables? Does LD_PRELOAD work for them?).

Peres: Wayland Compositors - Why and How to Handle Privileged Clients!

Posted Feb 28, 2014 8:03 UTC (Fri) by deepfire (guest, #26138) [Link]

Yes, I agree in that we ought to have separate means to close these weak spots.

And yes, whenever such security/flexibiility tradeoffs are introduced in future, they ought to be:

1. optional, with root-restrictable means of control
2. off by default

This is basic security, isn't it?