There are two cases in the code where a package tag is parsed. One is located where you pointed out. At the same hierarchical level as the signature and the default. The other is inside the determineInstallPolicyType function. This function is called when a signer stanza is encountered. When a package tag is found inside the signer tag the determineInstallPolicyType function calls itself again to ultimately determine the inner package stanzas own install policy. Look around line 73 in the PolicyParser.java file you referenced.
The intention of not denying install of the app after a failed signature stanza check is to allow the app to still be installed but with a different seinfo label by catching on a different stanza (package one or the default). So essentially a reduced set of selinux permissions would be used because of the different seinfo label. You could remove the default stanza completely and the app along with other apps that don't pass the signature stanzas you have set up will fail to be installed. But, we also realized that there could be cases where dropping the default stanza might not be useful. So we put in the package stanza as you have noted; listed packages would be denied but not all default ones. We found that this type of setup gave us more flexibility even though there was a bit of redundancy at times. So the analysis you gave is mostly correct. Based on your stanza below you could put an inner package tag inside the signer stanza that bounces just your app; I believe you had this type of stanza originally further down in this email. And then have either the default stanza missing or the included package name stanza that you have constructed to deny the app from installing. Note, we recently made some mods to the SELinuxMMAC.java file that has been accepted into Google baseline that we have subsequently merged into our seandroid branch. We decided to dispense with the permission listing component of this mechanism. Instead, the install-time MAC will only be responsible for assigning seinfo tags. We then offer the same type of "deny-permission" component via our Eops mechanism which is an extension to Android existing AppOps mechanism. So, in the future any confusion will be avoided like those you have described below. On Mon, Dec 9, 2013 at 11:52 AM, Severin Friede <[email protected]>wrote: > Dear Mr. Craig, > > i have checked my issues according to your guidance, but unfortunately i > could not solve the problem. I started debugging setool. The key > verification was correct. But i made a few concerns maybe you can help me > with them. > > When looking at PolicyParser::PolicyStart, the method sets policies ( > signature, package and default ) that are at the same hierarchical level. > But looking at the examples in mac_permissions.xml the package tag is a > child of the signature tag. The package tag is never been processed. > Putting the package at the same hierarchical level like signature, it > works. > > The PolicyParser::passedPolicy Methods has the following comment: > > > > /** > > * Policy checks work as follows: > > * We check all signature based policy first. If any of the signature > based > > * checks pass then we accept the app. If none pass then we further > check > > * for any package name or default based stanzas. Package names are > checked > > * first then default policy. > > */ > > I don't get the logic behind that method. I have wrote a signature policy > that denies permissions for my application. the policy did not pass what > was my intention but the default stanza will set it as "acccepted". i'll > have to write a package policy (at the same hierachical level) for the > application which makes the signature policy redundant. Am i thinking wrong? > > <signer signature="308203fb308202e3a00....."> > > <deny-permission name="android.permission.READ_EXTERNAL_STORAGE" /> > > <deny-permission name="android.permission.WRITE_EXTERNAL_STORAGE" > /> > > <deny-permission name="android.permission.ACCESS_NETWORK_STATE" /> > > <deny-permission name="android.permission.INTERNET" /> > > </signer> > > > > <package name="com.example.seandroid_storefiles" > > > <deny-permission name="android.permission.READ_EXTERNAL_STORAGE" /> > > <deny-permission name="android.permission.WRITE_EXTERNAL_STORAGE" > /> > > <seinfo value="gigatronik" /> > > </package> > > > 2013/12/5 rpcraig <[email protected]> > >> You might also want to make sure that the middleware mac is running in >> enforcing mode when installing apps for your tests. If you're in permissive >> mode and you try to install an app that is bounced by the mac_perms stanzas >> then you could still be installed and that might be what you're >> experiencing. We use a property key for this, persist.mmac.enforce. You >> can toggle this value by using "setprop persist.mmac.enforce 1" or by >> adding this to one of you .prop files in you build. We do have plans in the >> future to always be running in enforcing mode to avoid this. >> >> >> On 12/05/2013 07:44 AM, rpcraig wrote: >> >> On 12/05/2013 03:39 AM, Severin Friede wrote: >> >> Dear Mr. Craig, >> >> thank you very much for the answer. I followed your steps but >> unfortunately I could install apps signed with my own key that need the >> permissions i am denying. Could you please verify the following steps I >> have done so far: >> >> ------------------------------------------ >> >> 1.) mac_permissions.xml >> >> I created a new signer tag: >> >> <!-- university key --> >> >> <signer signature="@UNIVERSITY"> >> >> <seinfo value="university" /> >> >> <package name="com.example.seandroid_connectinternet" > >> >> <deny-permission name="android.permission.INTERNET" /> >> >> <deny-permission name="android.permission.ACCESS_NETWORK_STATE" /> >> >> <seinfo value="university" /> >> >> </package> >> >> </signer> >> >> When checking the new mac_permissions.xml file with setool i get the >> message that the policy is passed, but i shouldn, the app requested >> permissions for INTERNET and ACCESS_NETWORK_STATE: >> >> "MMAC policy passed for com.example.seandroid_connectinternet >> (/home/..../apps/signed_apk/SEAndroid-ConnectInternet_signed.apk)" >> >> >> If your passing the pre-generated mac_permissions.xml file to setool then >> your @UNIVERSITY key will not be expanded to a X509 cert (hex value). At >> this time, setool has no knowledge of a keys.conf file in order to make >> that kind of substitution. Therefore, setool tries to interpret that >> signature stanza and sees @UNIVERSITY as a non valid signature and the >> stanza is skipped. Since you have a default stanza, that is what is >> eventually checked and therefore passes. Best bet is to place the cert >> value into the signature attribute and rerun the tool. >> >> I assume you added this stanza to the >> external/sepolicy/mac_permissions.xml file? A better test might be to just >> build the mac_permissions.xml file with "mmm -B external/sepolicy/" after >> you make your change and then run setool against the generated file >> "out/target/product/mako/system/etc/security/mac_permissions.xml". You >> also might want to make sure that your @UNIVERSITY variable was properly >> expanded by just opening the generated mac_permissions.xml first. >> >> You mentioned that you could install apps signed with your key against >> this stanza. Was this tested on a phone or just by running the tool? If you >> could still install the app on a phone then that suggests the cert you >> generated is possibly bad. >> >> >> >> >
