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

Posted Feb 27, 2014 20:33 UTC (Thu) by deepfire (guest, #26138)
In reply to: Peres: Wayland Compositors - Why and How to Handle Privileged Clients! by alexl
Parent article: Peres: Wayland Compositors - Why and How to Handle Privileged Clients!

...which raises the obvious question -- why the hell can't we tag executables for non-LD_ROOTKIT-able interpretation by ld?

I can only find a semi-incoherent counter-point by Alan Cox[1] -- and it fails to convince.

--
1. http://lkml.iu.edu//hypermail/linux/kernel/0712.1/2040.html

to post comments

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

Posted Feb 28, 2014 3:58 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

There's __attribute__((visibility("protected"))) if you want to deny LD_PRELOAD overriding of a symbol (also helps avoid some -fPIC overhead since you don't need to go out to the GOT, just the PLT[1).

[1]Or something like that...I can never remember the PIC terms in the right order.

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

Posted Feb 28, 2014 6:24 UTC (Fri) by deepfire (guest, #26138) [Link] (2 responses)

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.

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?