I like all of the changes. I think the whitelist/blacklist rules being dropped. I don't like to use them, in practice it seems to be a maintenance nightmare.
On Thu, Nov 7, 2013 at 3:55 PM, Robert Craig <[email protected]> wrote: > > I would be disappointed if deny rules went away in the default stanza > though. > > Could you just make use of the new Eops mechanism for your scenario? So > allowing the app to install but then revoking the functionality from there. > Eops policy is written in terms of seinfo labels. I know the list of > operations that are supported in AppOps and subsequently Eops right now is > small but it appears to be an area of active development. For example, > there was about 12 new operations that were added with the new 4.4 release. > > > On Thu, Nov 7, 2013 at 1:55 PM, Joshua Brindle > <[email protected]>wrote: > >> rpcraig wrote: >> <snip> >> >> * Drop the allow-all, deny-permission, and allow-permission tags from >>> all stanzas. This should help reduce the size of the policy file and >>> adhere to the rule of least surprise when writing and using the >>> policy files. In effect, this would mean that all stanzas are >>> allow-all. In my own experiences I have found that the deny and allow >>> tags are really only used with default tag anyway. Plus, the >>> permissions component of the code was a big negative for Android >>> engineers. >>> >>> >> Agreed on the above. My personal experience is: >> >> 1) blacklist XYZ apps in one stanza >> 2) whitelist ABC apps in another stanza >> 3) either remove default altogether or limit the maximum permission set >> >> Sometimes I've used allow rules in package tags because I want to know if >> the package is updated and suddenly has more. This causes serious >> operational problems though (e.g., phones no longer have a launcher after >> updating). Probably not something that will ever work in production, >> unfortunately. >> >> I would be disappointed if deny rules went away in the default stanza >> though. >> >> >> * No package name stanza is possible outside of a signature tag. >>> Package names have no security associated with them in Android and >>> thus we should not be allowing or encouraging this type of policy. >>> Note, the package name tag would still be supported inside a signer >>> tag. >>> >>> >> +1 >> >> >> * No per package policy inside the default tag either. Again, since >>> the package name won't be tied to a cert it has no real security >>> benefit and we shouldn't be allowing such behaviour in policy. >>> >>> >> +1 >> >> >> * Policy is always in enforcing mode. If the default stanza is absent >>> then apps that don't pass one of the signer stanzas will not be >>> installed. If the default stanza is present however, all apps will be >>> installed. Passing a policy stanza would be if your cert and/or >>> package name passes, no perms involved. >>> >>> >> :( >> >> >> * Since the prior install-time mac made assurances about middleware >>> permissions the current model obviously can't quite achieve the same >>> notion. The prior model made permissions white-listed or black-listed >>> which provided some guarantee whether apps could retain those perms >>> on install. Obviously with the perm tag support on the chopping block >>> an alternate approach would be needed. Possible solutions could be >>> achieved by pairing the mac_permissions.xml policy with the new >>> eops.xml policy. Eops currently exists on our master and 4.3 branches >>> with an eye of porting this to 4.4 and will allow >>> permissions/operations to be restricted after install. While not all >>> permissions are covered by eops, work can be done to provide hooks >>> for the missing permissions in the future. >>> >>> Any changes that would occur would take place on our master branch >>> with a potential of being back ported if the demand was there. Other >>> potential improvements or cuts could be made if suggested and I'm >>> opening to ideas or criticisms of the current approach. >>> >>> >> -- >> This message was distributed to subscribers of the seandroid-list mailing >> list. >> If you no longer wish to subscribe, send mail to [email protected] >> the words "unsubscribe seandroid-list" without quotes as the message. >> > > -- Respectfully, William C Roberts
