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