On Apr 29, 2015, at 11:22 AM, Stephen Smalley <[email protected]> wrote:
> On 04/29/2015 10:53 AM, Stephen Smalley wrote: >> On 04/29/2015 10:10 AM, Clifford Liem wrote: >>> Background: >>> >>> We are using eCryptfs as a way to encrypt directories as well as PID >>> namespaces as a way to isolate processes. >> >> I believe Samsung has been using ecryptfs as well, not sure how they are >> addressing it, but perhaps they can do all of the mounting from vold or >> zygote. >> >> Wondering how use of PID namespaces might affect binder services that >> rely on the sender PID information provided by the kernel binder driver >> and those that rely on getpidcon(), e.g. servicemanager and keystore. > > BTW, what do you see as the security benefit of PID namespaces? They > are primarily advertised as a way to support process > suspend/resume/migration, not a security feature. > I think that suspend/resume/migration is just an example, but the collection of different types of namespaces as a whole is for security purposes. With PID namespaces we can isolate visibility of processes, as well as restrict signals (e.g. kill) along different namespace hierarchies. https://lwn.net/Articles/531114/ > If you just want to prevent accessing another process' /proc/pid files, > you can already do that via SELinux (if you run them in different > security contexts, either using different domains or levelFrom=), or by > using hidepid. hidepid looks interesting; however, this is not exactly what we are looking for, as it looks too oriented to unix userids. Android sandboxing and the abundant use of different unix userids would likely cause problems with zygote, etc. We’ve already solved the problem by using mount namespaces in /proc/pid (and also solved the binder services mechanics). This is much simpler than using seapp_contexts. Thanks again, Cliff
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
