> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Rafal Krypa > Sent: Wednesday, October 29, 2014 10:55 AM > To: [email protected] > Subject: [Dev] Setting Smack for Crosswalk processes > > Hello, > 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: > > https://github.com/crosswalk-project/crosswalk/pull/2397/ > https://github.com/crosswalk-project/crosswalk/pull/2518/ > > 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 > above > 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 > isolation. 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 > Smack. 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 > processes > > 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 > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
