What we do and don't expose to client toolkits

[William Hua]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I asked Jonas Adahl how the Wayland side is dealing with this, and
roughly:

Wayland doesn't see any of this as a security concern and broadcasts
the geometry of the display to clients:

https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n
2364

So, the menu positioning feedback is no concern either, and they
currently have an unstable protocol that notifies the client of where
its popup surfaces were actually positioned, relative to the parent
surface:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg
- -shell/xdg-shell-unstable-v6.xml#n1018
(same link referenced by Alan)

Jonas said there's some plans towards making this stable, but didn't
make any guarantees.

Wayland does prevent clients from knowing the absolute positions of
surfaces, but not for security reasons. More for being able to do
input transformations and non-traditional compositing. And if a client
goes out of its way to "probe" for its absolute position using this
feedback mechanism, that may end up working terribly since they're
making assumptions about undefined behaviour. For example, workspaces
larger than the display that are able to pan around.

Anyways, if we continue to specify display geometry as private
information, Mir needs to be smart enough to detect when a client is
abusing this new feature and disconnect them. Easiest thing I can
think of is a simple rate limit. We can also re-evaluate if it is
still worthwhile to prevent clients from knowing the geometry, but I
don't know the security implications there or the history behind this
decision.



On 2016-09-02 09:40 AM, Alan Griffiths wrote:
> On 01/09/16 12:02, Alan Griffiths wrote:
>> 
>> 
>> Thoughts and suggestions for the right way forward please.
>> 
> 
> A data point from Wayland 
> (https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/
xdg-shell/xdg-shell-unstable-v6.xml#n1018):
>
>  <event name="configure"> <description summary="configure the popup
> surface"> This event asks the popup surface to configure itself
> given the configuration. The configured state should not be applied
> immediately. See xdg_surface.configure for details.
> 
> The x and y arguments represent the position the popup was placed
> at given the xdg_positioner rule, relative to the upper left corner
> of the window geometry of the parent surface. </description> <arg
> name="x" type="int" summary="x position relative to parent surface
> window geometry"/> <arg name="y" type="int" summary="y position
> relative to parent surface window geometry"/> <arg name="width"
> type="int" summary="window geometry width"/> <arg name="height"
> type="int" summary="window geometry height"/> </event>
> 
> So (in their current "unstable" anyway) they are returning the
> relative placement. And running the risk of sneaky clients probing
> the display boundaries.
> 
> I claim this as "prior art" and propose that we do the same by
> sending a MirRectangle notification.
> 
> Any objections before the weekend please.
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXyYxRAAoJENtfC4FFqZmIgQkP/24EVx69iWlyjhlWeScYexeF
mVp8bhcORoLLxOn8ITKUGNqijrPYstDaaS8tr1QaMNZ/bZmqGi1pEUDnRTGitTn+
pn26Y+csOqiV+NducloBYhxVFkQeOMNciV0eWSFvPR8OF0J/Kv0Jti+5MNb5JTSc
y+L/zcHDcQFKb1Q9hmlinIZ97GSGiKP7vp8tzzdiehgFcTYncRYryAMqcIern6iD
s27gQpZkRLGryMdRo1Bcl17zoH5m5E3X6dFxN0j4CxXTVK0enSY454ODVPYHIcdm
Tm/Az5ufB4u1mP4yhWT4KN3FV9Obt1by7PiHfjChObPWoIhNObcA+2WfG0C4w+Kf
sLLrO+gKRXqfz6XA8WW4clzxCMRdpIhbKNbModZiHjUSQ7e0ODmD/YRE3f7yy/LF
NcU4mu6gAiobyqb1kbtI/BLUHPfFk2JCv61FUOnA3kzLcjf0OY8L/ySOSc+SXMxr
L3Ew6MDkvQXpilDMHvuJjNPzu9nJQIIDAYJ3YLJQRGzPm9jjPVPVf0qnQG/ptUu1
KbWE0WqAzEwcOtKuMNJO2+nZUHADV4OKzZjQJx8/hLoHN0e14wTk+aSBCsuo6y2v
e2rwhIX8eTVfasmtDgb3XqlDbE9CTaqMwosEaPsCNq/ypI2EG2lcZXqv42+ornYc
L0j0R3PUl6AJLODN4rMg
=iIEA
-----END PGP SIGNATURE-----