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] with
the words "unsubscribe seandroid-list" without quotes as the message.
