1. Can the debug application be run in a seperate, elevated domain that is mlstrusted? You could also strip the rules on user builds like what is done for su 2. If its shell, you can add permissive into the shell domain, or use su, just make sure to drop the permissive statement prior to ship
I would go with number 1. Sounds like you have a debugging application where you control the key to that app I would add your application into a higher privelege domain... 1. extract the pem file from the apk... 2. Add the configuration to keys.conf 3. Set up the mac_perms.xml entry 4. Set up the seapp_contexts entry That should get you to where you want to be. Bill On Mon, Oct 14, 2013 at 3:01 PM, Tai Nguyen (tainguye) <[email protected]>wrote: > No, our product version has problem reporting mechanism which uses 'ps'. > > On 10/14/13 5:59 PM, "Radzykewycz, T (Radzy)" <[email protected]> wrote: > > >From what you've said, I guess this is for a debug version, and not for > >actual deployment. If so, it might be possible to disable enforcing when > >ps is run for troubleshooting, and re-enable it afterward. > > > >Other alternatives might be a policy variable to allow/deny ps during > >debug, or a modified policy for use during debug. Or both. > > > >________________________________________ > >From: [email protected] > >[[email protected]] on behalf of Tai Nguyen (tainguye) > >[[email protected]] > >Sent: Monday, October 14, 2013 1:27 PM > >To: William Roberts > >Cc: [email protected] > >Subject: Re: Security Context with category constraint for untrusted app > > > >Our main problem with the constraints for untrusted apps is that the > >output of 'ps' doesn't contains those apps. We use 'ps' for trouble > >shooting purpose (e.g., trouble reporting), thus, we need complete view > >of the system (i.e., all processes are currently running). > > > > > > > >From: William Roberts > ><[email protected]<mailto:[email protected]>> > >Date: Monday, October 14, 2013 5:20 PM > >To: Tai Nguyen <[email protected]<mailto:[email protected]>> > >Cc: "[email protected]<mailto:[email protected]>" > ><[email protected]<mailto:[email protected]>> > >Subject: Re: Security Context with category constraint for untrusted app > > > >This way the mls constraints take affect, so you can get finer control > >over app permissions. For instance, the constraint on files prevents > >another app from reading some other apps private files if they left it as > >world readble (Ala Skype issue IIRC) > > > >Constraints are one of the most incredible features of SELinux. I would > >recommend reading up on them fully and making sure you really want to > >disable levelFrom=<something> > > > >AOSP has it set to levelFrom=none (same as removing it) for compatibility > >reasons. One of them being apps can no longer use world accessible files. > > > >NSA has it set to levelFrom=app > > > >Another option is to re-write a constraint that is given you problems to > >something that meets your needs. > > > >FYI seapp_contexts and mls (and all policy files) are controllable via > >BOARD_SELINUX_REPLACE BOARD_SELINUX_UNION. > > > >Some files, like seapp_contexts go through further processing via > >checkseapp. If you havent I would read the README in external/sepolicy. > > > > > > > > > > > > > >On Mon, Oct 14, 2013 at 1:30 PM, Tai Nguyen (tainguye) > ><[email protected]<mailto:[email protected]>> wrote: > >Thanks, Bill. I wonder what is the reason to set the levelFrom for > >untrusted app. > > > >Tai > > > >From: William Roberts > ><[email protected]<mailto:[email protected]>> > >Date: Monday, October 14, 2013 3:21 PM > >To: Tai Nguyen <[email protected]<mailto:[email protected]>> > >Cc: "[email protected]<mailto:[email protected]>" > ><[email protected]<mailto:[email protected]>> > >Subject: Re: Security Context with category constraint for untrusted app > > > >in seapp_contexts remove levelFrom for untrusted_app > > > > > >On Mon, Oct 14, 2013 at 12:08 PM, Tai Nguyen (tainguye) > ><[email protected]<mailto:[email protected]>> wrote: > >Hi, > > > >On our devices, there are couple (untrusted) apps that have constraint in > >security context. How do these apps get the constraint in their security > >context? > >How do I remove these constraint? > > > >root@android:/proc/2339 # ps | grep contacts > >u0_a1 2339 167 474780 31300 ffffffff 40023a60 S > >com.android.contacts > >u0_a55 3338 167 470356 29876 ffffffff 40023a60 S > >com.cisco.contacts.udssync > >root@android:/proc/2339 # ls -Z /proc/2339 > >dr-xr-xr-x u0_a1 u0_a1 u:r:untrusted_app:s0:c1,c256 attr > >-r-------- u0_a1 u0_a1 u:r:untrusted_app:s0:c1,c256 auxv > > > > > >Thanks, > >Tai > > > > > > > >-- > >Respectfully, > > > >William C Roberts > > > > > > > > > >-- > >Respectfully, > > > >William C Roberts > > > > -- Respectfully, William C Roberts
