> 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. >
