New HMI should be the only authoritative source of surface ID

Any update or can we close this issue ?

Regarding security, it is not limited to WindowManager.
I would like to discuss what to do as AGL as a whole.

Thanks for comments and information, Stephane. This is helpful. I found that id-agent is in the ivi-shell and maybe it is the publisher of surface id and security checker.

For XDG-shell application, please XDG-shell application just write the image without patching. After reworking, window manager hooks the notification from ivi-wm and show it. (I will update the sequence for XDG) . So XDG-shell app doesn't need to speak to window manager. (Window manager controls surfaces in background).

In next step, window manger has to classify the application from surface id for policy management.

Thanks again for the comments.

My understanding is that applications should not have to make explicit requests to the windowmanager.
Otherwise, we won't be able to run XDG apps like Chrome without patching their source code. And the patch will have to be maintained in AGL for a long time as it's very probable that nobody in the chromium project will accept such specific patches !

The final architecture should be closer to the one proposed by Michael Teyfel/ADIT::
https://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20171115/00a3be47/attachment-0001.pdf (slide 8)

In this architecture::

• XDG apps don't make any request to windowmanager

• IVI apps speak "IVI protocol" but should not request directly to windowmanager

• AGL apps (not represented on ADIT drawing) could use XDG or IVI protocol with compositor + make direct calls to windowmanager/homescreen APIs (through bindings)

The component named "id-agent" (or windowmanager indirectly) could do the necessary security checks.

Tasks here

• Improve security

• Show XDG-Shell application (ivi-shell supports xdg-shell for desktop application from ivi-2.X version)

  • We need to consider how window manager classify and authorize the applications from surfaceID.

• Support multiple display

In F2F meeting, we discussed with Tanikawa-san. Then as first step, we rework for the following for next integrate session.

• "Layer" should be the logical container not for the feature such as "popup", "apps", "homescreen" and so on, but for the logical group of  surfaceID for same applicaiton. For example, Navi application may consist of some processes and they have some own surfaces. but they are the group of Navigation. In this case, layer id is the logical container of surface ids means application. To maintain the idea of "popup", "app", "homescreen" (group of layer), window manager supports the interval of layerID for the group.

• To authorize the application, window manager publishes the session ID for each app. In current implementation, window manager returns surface ID. But this is not better for security. Until working with ID agent, window manager returns session ID instead of surfaceID in registration. Window manager generate the layer ID and bind it to session ID. This protects the impersonation of layer ID.

• To support ivi-shell version 2.X, Window Manager uses ilm API instead of ivi-controller protocol.

• To support XDG-shell application, Window Manager hooks the notification from ivi-wm, and create layer then render it.

• Support API to get screen info.

We need to discuss with ADIT to enable window manager works with ID agent.