On Apr 29, 2015 7:45 PM, "Clifford Liem" <[email protected]> wrote: > > Thanks for your comments. > > On Apr 29, 2015, at 11:33 AM, William Roberts <[email protected]> wrote: > >> >> On Apr 29, 2015 8:27 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. >> >> Yes network and mount table name (IIRC clone_netns and clone_ns) flags are handy for isolation but not pid. > > Yes, we’re using mount and network namespaces as well. > >> > >> > 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. >> > >> >> As far as cdd recourse, their is a waiver process however im more in the mindset of fixing limitations on master or the design causing the issue, and frown on waivers. > > I agree. We would rather fix limitations in the design than look for a waiver. > > Perhaps we can explore Forrest’s (Samsung) idea of pushing a PR back to AOSP that considers expanding the design of the neverallows. > (Thanks for that, Forrest!)
That's what I meant above on fixing limitations on master. > > 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]. > >
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
