William Roberts wrote:
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.
And wait months to get it through the carriers? Please no.
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.
Or not, since the kernel does not need to know about those other files.
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.
Which aren't even close to the same thing as policy. This is definitely
something that needs to be done in userspace, and can easily do so in a
trusted way using domain transitions and only allowing the loader to
load policy. Samsung devices already support signing the policy updates
sent down from their policy server, so it would not be a far leap to
remove the ability of everything else to load policy.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
