Hi,
I wanted to get a feeling for everyone's use of install-time mac and
the experiences they have had
with it, both operationally and for development. I'm proposing some
changes to the code base that
are intended to help trim back the size and scope of install-time mac in
hopes that we can better merge
with AOSP and thus keep us on a track that is more acceptable by Google
with future changes. In
addition, all ancillary tooling would become vastly simpler and the
build harness support becomes less
of an issue to maintain. The idea would be to keep the functionality
that is desired and used by most
while allowing similar functionality that is being trimmed through other
means (eops, intentfirewall).
Here's the skinny on some of the proposed changes I had in mind.
* 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.
* 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.
* 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.
* 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.
Thanks
--
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.
