These changes to install-time MAC and the mac_permissions.xml configuration have been backported to our 4.4-based branches. Our 4.3-based branches still have the older code and configuration.
The changes and updated syntax for using setool are now described in the wiki, http://selinuxproject.org/page/SEforAndroid#4.4_and_later At this point, our install-time MAC code is almost identical to AOSP master except for: 1) We support assigning seinfo values to non-system apps as well as system apps (AOSP treats all non-system apps identically). This is merely a three line difference in SELinuxMMAC.java to comment out the AOSP check to see if the app is a system app or not. The benefit of our approach is that you can place non-system apps in domains other than untrusted_app based on their certificate, e.g. an app installed via Google Play that was not pre-installed can be assigned a specific seinfo tag and placed in a more privileged domain than untrusted_app. 2) If an app does not match any stanza in mac_permissions.xml (and there is no default stanza, which would match anything), then our code refuses to install the app. This is a few lines difference in PackageManagerService.java. The benefit of our approach is that we can use install-time MAC to white-list all apps that can be installed on the device by removing the default stanza from our policy and then explicitly enumerating all allowed signatures and/or packages via signer and/or package stanzas. On 12/11/2013 01:02 PM, rpcraig wrote: > Hi, > > We've recently merged some new changes to our install-time MAC > implementation on our seandroid branch. These changes reflect those that > had been outlined and discussed in a prior email. This new set of > changes allows us to be almost entirely consistent with AOSP and their > implementation. In fact, we've recently merged in a few changes to AOSP > to enrich their feature set and plan to do future development entirely > with the AOSP version. While a few things have been dropped from our > original implementation, we feel that the functionality that is desired > and used by most was kept and are allowing similar functionality that is > being trimmed through other means (eops, intentfirewall). We're also > looking to merge this set of changes into our existing 4.4 branch for > those of you who track more stable releases. Unless, of course, there > are any major objections to this back-porting. Here are some of the > changes: > > * Dropped the allow-all, deny-permission, and allow-permission tags from > all stanzas. > This helped 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 now means that all > stanzas are allow-all. By > the way, according to most implementations that we have seen everyone > uses allow-all anyway. > > * 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 is 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 is if your cert and/or > package name passes, no > perms involved at all. This is the difference that exists between our > implementation and AOSP's > version. The AOSP version will *always*install the app regardless of a > default stanza (it just > assigns "null" as the seinfo label). > > * Since the prior install-time mac made assurances about middleware > permissions the > current model obviously can't quite achieve that same notion. The > prior model made > permissions white-listed or black-listed which provided some guarantee > whether > apps could retain those perms on install. A similar approach can be > taken with our new > Eops implementation (seandroid, 4.3, 4.4 branches) which allows the > eops.xml > configuration file to be paired with the mac_permissions.xml policy. > Eops allows > permissions/operations to be restricted after install based on > assigned seinfo labels. > We see this as a viable way forward with revoking operations granted > to apps on install. > In some sense achieving the equivalent of "deny-permission". We are > also actively > developing against the IntentFirewall functionality (not released yet) > that should help > close some of the additional gaps left by trimming the install-time > MAC code. > > * setool has been modified to account for the new supported syntax and > viable tags > in mac_permissions.xml. Just rebuild setool and run "setool --help" > for further guidance. > > * For most existing mac_perm files, little to no change is needed as > the now non-supported > tags are simple ignored. There might be a few cases out there where > you'll have to reorder > your seinfo tags in order to be compliant. Consult > external/sepolicy/mac_permissions.xml > for further guidance. > > > > Some of the relevant changes: > frameworks/base.git > 2a171992b447f3b47fcadeb101c38e3c9e07df45 > 99a626c2719e1965364fad543101799f527e28ca > > external/sepolicy.git > 51269a0f77523837106c9c896515dc8b7cd727ef > 7698f584ee94655d87106c0120b180c425955fc6 > d031706df94ced3d1514606f4b7cc2f6e02e785c > _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
