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 > -- 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.
