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

Posted Feb 20, 2014 20:11 UTC (Thu) by uoppy (guest, #95651)
In reply to: Peres: Wayland Compositors - Why and How to Handle Privileged Clients! by uoppy
Parent article: Peres: Wayland Compositors - Why and How to Handle Privileged Clients!

And of course the server must put the path to the executable in the titlebar, in a way that cannot be overridden by the application, or alternatively, a "badge" to identify applications that are either signed or in a system path.

BTW, input confidentiality also means that new windows must not initially overlap existing windows or be raisable to be so (or you can steal clicks and later keyboard input), and that applications must not be able to steal input focus.

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

Posted Feb 21, 2014 9:52 UTC (Fri) by dgm (subscriber, #49227) [Link]

What you're proposing is very similar to what web pages use today. And it doesn't work, the users are too easily fooled.

An alternative that could possibly work is to use an intermediary application that could authenticate the application requesting the password, and teach the users to _always_ use that intermediary application.

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

Posted Feb 21, 2014 12:36 UTC (Fri) by alexl (subscriber, #19068) [Link] (5 responses)

Execurable paths are useless, just LD_PRELOAD your code and run it as any binary you want.

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

Posted Feb 27, 2014 20:33 UTC (Thu) by deepfire (guest, #26138) [Link] (4 responses)

...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

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?