[Dev] Setting Smack for Crosswalk processes
casey.schaufler at intel.com
Thu Oct 30 15:20:55 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Rafal Krypa
> Sent: Wednesday, October 29, 2014 10:55 AM
> To: dev at lists.tizen.org
> Subject: [Dev] Setting Smack for Crosswalk processes
> The process of integration of Crosswalk with security-manager for proper
> handling of application privileges is ongoing. Lately it happened mostly on
> Crosswalk Github. Two patches are now pending:
> There have been some concerns and issues that I'd like to discuss here. I
> have also some new questions about Crosswalk architecture and different
> kinds of processes.
> As we agreed talked over several times, each app should have it's own
> render process and extension process, both run with application-specific
> Smack label. And there is the browser process, common for all apps of a
> single user. While setting Smack for EP is easy and already implemented in
> patch, doing this for RP isn't that simple.
So I have heard.
> If I understand it correctly from the Crosswalk point of view, RP is being
> created by underlying chromium components. It is by default "sandboxed"
> with seccomp2. The limits of that sandbox, once sealed, prevent Smack label
> change. Therefore crosswalk cannot call security-manager in the render
> process to manipulate Smack. There have been voices that Smack cannot be
> setup for RP or that it's not necessary, because sandbox already provides
The Crosswalk/Blink/Chromium sandbox is irrelevant.
It does not reflect the Tizen security architecture in any way.
> I have few concerns with that approach:
> - The construction of Crosswalk sandbox should be investigated to check
> what it actually allows. It may or may not offer higher levels of isolation than
It could provide additional security.
> - Smack is supposed to be used for identification of application processes. If
> RP can access any process other than BP, then without proper Smack labeling
> the other process won't be able to securely identify the web application. Can
> we get a confirmation from Crosswalk developers that such
> communication should not happen?
A compromised RP may attempt to access things it oughtn't.
> - Sandbox setup seems to be completely optional. If Crosswalk is unable to
> setup the sandbox (e.g. because kernel was compiled without seccomp2
> feature), it continues to work without it. This makes the whole sandbox thing
> unacceptable as a replacement for "Smack sandboxing".
There is no acceptable replacement for setting the Smack label correctly.
> As for other questions about Crosswalk, I discovered two other kinds of
> processes that doesn't fit into (BP, RP, EP) categories:
> - zygote - spawned from the BP, it seems to be the one forking render
> processes (not the BP itself)
> - gpu-process - spawned from the BP, it doesn't seem to fork any other
> So instead of single BP process per user, as I expected, there are three of
> them. Could some Crosswalk expert briefly explain their purpose? Because
> setting Smack label requires capabilities, all of these processes would be run
> privileged. If the zygote process is the one spawning render processes,
> the other two actually don't need the capability and should probably be
> modified to drop them. More patches need to follow...
> Best regards,
> Rafal Krypa
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev