On Aug 21, 2015 4:44 PM, "Joshua Brindle" <[email protected]> wrote: > > William Roberts wrote: >> >> All, >> >> Some of the more recent attacks I have seen, once in the system server, >> reload the SELinux policies. This API is currently required by the CDD and >> seems to be in use by various OEMs. This makes me wonder if we should >> propose killing this API and only load of the ramdisk or if we must keep it >> support signing the SELinux policies and have the kernel verify them. >> >> Which way should we proceed on this topic? >> > > Not being able to update policies seems like a non-starter, both from a need-to-fix-this-for-compatibility and from a security issue perspective.
OEMs could just push an OTA, not saying they should be forced down that route though. Which is why policy verification is so important. > > But having the kernel verify is not ideal either, especially since there are many parts of the policy that are not kernel related. We could start with the policy binary and move from there if needed. Especially considering that the policy controls relabelling ability. > > It wouldn't be hard to make system_server domain transition to a trusted loader that did a signature check, and to ensure that the trusted loader is the only thing with permission to load policy, though. System server just triggers the reload. Init loads it into the kernel.. init could check. However, I dont want to bloat init with this considering the kernel already has suppor for signing kernel modules.
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
