Rafal, I add the comments below yours.
Best Regards Zhang Xu > -----Original Message----- > From: Rafał Krypa [mailto:[email protected]] > Sent: Friday, November 7, 2014 10:08 PM > To: Zhang, Xu U > Cc: [email protected]; Pozdnyakov, Mikhail; Oda, Terri > Subject: Re: [Dev] Setting Smack for Crosswalk processes > > On 2014-11-07 06:28, Zhang, Xu U wrote: > > Rafal, > > > > I have a question on API to drop privilege. Is this API affected by > sandbox(seccomp)? As you pointed before that GPU process is restricted in > sandbox and we also need drop privileges by calling API of security manager, I > want to make clear it. > > Hi Xu, > Two things about your question: > > First, from what Mikhail Pozdnyakov wrote in his e-mail, I understood that GPU > process is not restricted by sandbox. If render processes need to delegate > their > GPU stuff to the GPU process because they are sandboxed, what good would it > do if the GPU process was sandboxed as well? > [Zhang Xu ] I don't see GPU process is not restricted by sandbox from Mikhail's email. You can find the sentence below from http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome "GPU process running in a less restrictive sandbox that allows access to the platform's 3D APIs" > Second, whether or not the sandbox would interfere with > security_manager_drop_process_capabilities() depends on actual sandbox > implementation. The capability dropping function relies on capset system > call. I > don't know which system calls are affected by chromium sandbox. It would be > very beneficial to actually know the seccomp-bpf filters configuration used by > chromium. Would you be able to provide such information? > > [Zhang Xu ] The policy for render and GPU process is different. Policy for render process can be found from ${Chromium}/src/content/common/sandbox_linux/bpf_renderer_policy_linux.cc: RendererProcessPolicy::EvaluateSyscall() function. Because there are some sysno instead of system call listed in this function, we have to convert sysno to system call later. I copy the code below for reference. ResultExpr RendererProcessPolicy::EvaluateSyscall(int sysno) const { switch (sysno) { // The baseline policy allows __NR_clock_gettime. Allow // clock_getres() for V8. crbug.com/329053. case __NR_clock_getres: return sandbox::RestrictClockID(); case __NR_ioctl: return sandbox::RestrictIoctl(); // Allow the system calls below. case __NR_fdatasync: case __NR_fsync: #if defined(__i386__) || defined(__x86_64__) || defined(__mips__) case __NR_getrlimit: #endif #if defined(__i386__) || defined(__arm__) case __NR_ugetrlimit: #endif case __NR_mremap: // See crbug.com/149834. case __NR_pread64: case __NR_pwrite64: case __NR_sched_getaffinity: case __NR_sched_get_priority_max: case __NR_sched_get_priority_min: case __NR_sched_getparam: case __NR_sched_getscheduler: case __NR_sched_setscheduler: case __NR_sysinfo: case __NR_times: case __NR_uname: return Allow(); case __NR_prlimit64: return Error(EPERM); // See crbug.com/160157. default: // Default on the content baseline policy. return SandboxBPFBasePolicy::EvaluateSyscall(sysno); } } > > Best regards, > Rafal Krypa > > > >> -----Original Message----- > >> From: Rafał Krypa [mailto:[email protected]] > >> Sent: Tuesday, November 4, 2014 6:02 PM > >> To: Zhang, Xu U > >> Cc: [email protected]; Pozdnyakov, Mikhail > >> Subject: Re: [Dev] Setting Smack for Crosswalk processes > >> > >> On 2014-11-04 09:25, Zhang, Xu U wrote: > >>> Hi Rafal, > >>> > >>> I have forwarded your email to Crosswalk mail list. Misha , who is > >>> key > >> contributor for Crosswalk reply here: > >>> https://lists.crosswalk-project.org/pipermail/crosswalk-dev/2014-Oct > >>> ob > >>> er/002165.html > >>> > >>> I have a question on setting SMACK label for gpu process. GPU > >>> process is > >> shared by all render process in the same user just as browser > >> process. What SMACK label should be set for GPU process? What API should > we call? > >> > >> Hi Xu, > >> Let me summarize the whole picture including the GPU process and the > >> Zygote process and how I think they security configuration should be > handled: > >> > >> *Browser process* > >> Will be launched by "systemd --user". Runs with label "User" and with > >> privilege (capabilities for setting Smack labels). You don't have to > >> call anything to change it's security settings, with one exception > >> (described > below at Zygote process). > >> > >> *GPU process > >> *Spawned from the browser process. Runs with label "User" and > >> inherits the privilege from the browser process. Since it doesn't > >> need the privilege, it should call > security_manager_drop_process_privileges() function. > >> > >> *Zygote process > >> *Spawned from the browser process. Runs with label "User" and > >> inherits the privilege. I need to know if Zygote will continue to be > >> used on Tizen. If yes, then the browses should drop capabilities > >> after spawning Zygote (security_manager_drop_process_privileges()). > >> Whichever process will spawn render processes, needs privileges to pass > them to render children. > >> > >> *Render process > >> *Spawned from Zygote process, or directly from Browser process if > >> Zygote is gone. It will run with application-specific Smack label. > >> Will be initially started with privilege to allow changing of Smack > >> label. Should call > >> security_manager_prepare_app() to set security context, which will > >> change the label and also drop privileges. > >> > >> *Extension process* > >> Will be spawned from application launcher (amd_session_agent, but see > >> also https://bugs.tizen.org/jira/browse/TC-1968). It should run with > >> application-specific Smack label. Tomasz Iwanek patched Crosswalk to > >> call security-manager in EP, but after we integrate amd with > >> security-manager, that won't be needed. The launcher should take care > >> of setting security for EP and you won't have to do it in Crosswalk. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
