> - 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.
Did you mean no policy or program originated outside from boot image ? If it is policy, would not that break policy update? On Wed, Aug 27, 2014 at 12:27 PM, Stephen Smalley <[email protected]> wrote: > 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 [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
