On 08/27/2014 01:43 PM, Dinesh Garg wrote: >> If someone is able to store/overwrite policies in /data, it would create a >> persistent breach of policies. Instead, if we deliver OTA as boot.img > which >> is verified every time device boots up, it would prevent any such >> persistent threat. >>> Not necessarily, unless you take steps to ensure that there is no other >>> way that policy can be loaded after the initial load. > I did not understand this. Can you please elaborate a little more ?
AOSP master policy only allows the init domain to load policy into the kernel. But init does execute some programs from /system without changing domains, e.g. fs_mgr can invoke e2fsck or mkswap, and not every service in init*.rc or init.<board>.rc has a domain transition or seclabel defined, so if you can write to /system, then you can potentially get code execution in the init domain and therefore load any policy you please. Ways to prevent this would include: - Remove load_policy altogether from the policy, even from init; initial policy load will still be possible because everything is allowed until a policy is first loaded, but runtime policy reload will not be possible. This however would break the ConfigUpdate mechanism. - Set up domain transitions for all /system programs invoked by init and then prohibit executing anything from /system without changing to another domain. This would still leave open the option of runtime policy reload by init but ensure that nothing originating outside the boot image can ever use that permission. That's the better option IMHO. >>> It was our impression that requiring a firmware update for every policy >>> update would be an obstacle to adoption, although we have no hard data >>> there. Particularly for early adoption where policies may not yet be >>> sufficiently mature/robust for every contingency. > Are you suggesting that delivering policies through firmware upgrade is a > safer mechanism compared to configupdate ? Safer from a mechanism point of view; could be less safe/secure in its ultimate effect though (e.g. only supporting policy update via firmware upgrade could discourage OEMs from shipping stronger policy in the first place for fear of breakage that wouldn't be fixable without an OTA, and would likely make it just as cumbersome to ship policy fixes to close vulnerabilities as it is to ship the corresponding code fix, thereby negating one of the potential benefits). Likely better to just improve the security of the ConfigUpdate mechanism. >>> Under AOSP master policy, only the system_server can modify >>> /data/security, which is required so that the ConfigUpdate mechanism can >>> write the policy files there after validation. > Do you envision any way there could be privilege escalation despite > SEAndroid ? Of course; kernel vulnerabilities remain a concern and one can always seek to carve a path through the allowed policy for userspace (i.e. find a domain that is allowed to do what you want to do by policy because it is part of its legitimate purpose, find a vulnerability in that corresponding program and get code execution in that domain). And of course it all depends on how good the policy is in the first place. >>> An alternative would be to have init or the kernel verify a signature on >>> the policy before loading it, in which case merely being able to write >>> to /data/security is no longer sufficient to get a policy loaded. That >>> would be possible (with code changes to init or the kernel). > This sounds good. Do you plan to upload code changes? Probably need to first determine which approach is preferred (kernel or init). init would probably be easier and more portable since there is already a worked example of signature verification in the recovery and I think the current Android kernels are too old to include the asymmetric crypto support added for module signing. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
