Thanks for the quick response and I can confirm your patch works fine. I'm planning to add the info I've found regarding CP_MAC config to the selinuxproject.org site along with the stuff I added a few weeks ago, probably within the next week or so. I'll extract any info you provide in the config files and add it to the site.
I know its all experimental but are there any plans regarding CP_MAC and Intent_MAC about how they will be developed and whether they will be seen in Android AOSP releases. Thanks again Richard ----- Original Message ----- From: rpcraig <[email protected]> To: Richard Haines <[email protected]> Cc: seandroid <[email protected]> Sent: Friday, 28 June 2013, 15:23 Subject: Re: CP_MAC not obtaining correct content_permissions.xml file entries On 06/28/2013 08:29 AM, Richard Haines wrote: > I've been experimenting with the Content Provider MAC using a resolver app > installed as "untrusted_app" and a Content Provider installed as > "release_app". > The device content_permissions.xml file entries are shown below that were > added as a BOARD_SEPOLICY_UNION in the device BoardConfig.mk file. > > The problem is that when setTypes() is called by the PM the > "demo_resolver_package" type entry was never selected. This is because the > code in ContentSecurityManager.java selected the first match on the signature. > > The attached patch will now check if the package the PM is processing has a > matching "package value=" entry in the package types and if found process > these first. > > I'm not sure if this is the best way but does at least work (note if the > content_permissions.xml file entries shown below are added at the beginning > of the external/sepolicy/content_permissions.xml, then they would be found > without the patch, simply because the sigs match first). > > content_permissions.xml file entries: > <policy> > <!-- Resolver Package Type --> > <type name="demo_resolver_package" component="package"> > <package value="com.example.resolvecontentdemo" /> > <permission value="com.example.contentprovider1.READ" /> > <permission value="com.example.contentprovider1.WRITE" /> > </type> > > <!-- Provider Content Type --> > <type name="demo_provider"> > <package value="com.example.contentprovider1" /> > <signature value="@RELEASE"/> > <provider value="com.example.contentprovider1.contentproviderdemo"/> > <export-read value="normal" /> > <export-write value="dangerous" /> > </type> > > <allow-content> > <allow source="demo_resolver_package" destination="demo_provider" >permission="use;rw"/> > <allow source="demo_resolver_package" >destination="settings_provider" permission="use;r"/> > </allow-content> > </policy> > > Richard Try the patch below instead (I'm presently building and testing right now it but it should work....). When the content_permissions.xml file is read, the stanzas are then sorted based on a set of precedence rules found in ContentSecurityManager.java (look for the 'packageComparator' object). The sorting ensures we only ever assign one type per package by the PMS. This is also the same type of logic used for assigning types to the content providers just using a different sort function. The original sorter for packages only considered if the signature tag was present in the package stanza policy. This helps explain some of the behaviour you outlined above. Essentially, if your stanza is missing a signature tag it will be of equal precedence when compared to other stanzas without a signature tag. Since our ref policy also includes a 'default_package' type (no child tags attached and therefore really meant to serve as a catch all), this will be selected over other entries that are added after it which don't have a signature tag. This might also explain why if you place your stanza first in the file instead of with the UNION construct it seems to work. We just need to beef up the comparator to sort based on more selectors -- the attached patch does this. Since the cp_mac is largely experimental in nature, our documentation is this area is a bit lacking. I'll see if I can't just add some comments to the top of the content_permissions.xml file to avoid future headaches. I'll get some additions pushed to the cp_mac to add the precedence rules and some greater guidance on configuration. -- 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.
