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

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

They are forgetting one of the most important issues: authentication of applications to the users.

That is, knowing that the Firefox window is indeed Firefox and not another application copying the Firefox UI to steal the users' password.

This requires server-side decorations AND either randomizing the decoration appearance and keeping it secret or connecting windows to the edge of the screen with a bar (to prevent simulating a fake window inside a legitimate window).

to post comments

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

Posted Feb 20, 2014 20:11 UTC (Thu) by uoppy (guest, #95651) [Link] (7 responses)

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 (guest, #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?

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

Posted Feb 20, 2014 20:17 UTC (Thu) by mupuf (subscriber, #86890) [Link] (1 responses)

Well, that's a valid concern and a funny proposal you have, but that's entirely up to the compositor to implement it. We don't need any protocol here so it is a little out of the scope of the article ;)

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

Posted Feb 27, 2014 10:30 UTC (Thu) by renox (guest, #23785) [Link]

> but that's entirely up to the compositor to implement it.

Not true: this also requires that there is a protocol to tell clients that the server has server side decoration so clients shouldn't render their decoration otherwise it wouldn't look good with 'double decoration'.

Fortunately (AFAIK), this is not a problem as the protocol exist..
[ let's just hope that those who push for client side decoration in the name of performance don't remove support for this protocol.. ]