The browser process is a security enforcing component
of the system already. It will have all the information
required. The browser process can make the security check.
This is not a security check but rather to pass extra information to
Weston/Wayland, for the later to report it to Murphy.
In that case the Browser process needs to store the AppID of the
requesting App, pushes it to Weston/Wayland (the preferred mechanism
still needs to be defined).
This is also possible. In the browser process:
Fetch the Smack label for the App (details left as an exercise)
Set the SMACK64IPOUT attribute on the socket to Weston to that
Send the request
I would suggest that having the browser process do the check
is likely to be simpler, perform better and be easier to debug.
Yes such a model would be nice and "simple" as Crosswalk woudl behave
like any other Apps.
Depending of the selected model, Weston/Wayland may need to check that
the requesting App has the privilege to act as a proxy for a third party
before accepting the request (what would be the case of Crosswalk
rendering process).
Does the App have the Proxy privilege? I don't see an issue here.
How is this special?
Issue is not open a hole where any application has a way to make a
request under an other AppID.
We can trust Crosswalk but not any other native App.
Then Weston/Wayland would need to implement a secured and trusted
interface to provide the information to Murphy and accept enforcement in
return.
OK, sounds like we need a diagram of who I talking to whom.
If it turns out to be what I think it is, we may have to raise Murphy's
awareness of security attributes.
Yes.
Dominig
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
