Thanks Stephen, Thought I have latest local_manifest, I had to sync this morning, seeing new changes, will let you know how it goes. -Subbu On Thu, Mar 8, 2012 at 11:18 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Thu, 2012-03-08 at 11:09 -0500, Subramani Venkatesh wrote: >> Hi Stephen, >> I collected some log about AVC denial running CTS in permissive mode, >> I am seeing most of the calls being denied on binder( receive and >> call), and all CTS apps are under untrusted_app domain, though I can >> add the fix in cts.te to continue da CTS, I am concerned in >> future if someone enables android_cts and still can install some >> untrusted app( May be not part of CTS). How does this work? or is >> android_cts is for only development platform? > > Did you update to our latest policy? Make sure you use the latest > local_manifest.xml file, > http://selinuxproject.org/~seandroid/local_manifest.xml > so that you use our sepolicy project and not the (not yet updated) AOSP > one. Then run repo sync -j1 with that local_manifest.xml file in > your .repo subdirectory. > > The denials you listed should already be fixed with our latest tree. > I'm still investigating some other denials during CTS execution. > > The concept of the android_cts boolean is to allow certain permissions > for the CTS instrumentation on the device that aren't > necessary/desirable for production devices. So it would only be enabled > when running the CTS normally. > > An alternative would be to assign the CTS packages specific app domains > by specifying their package names in seapp_contexts and defining a > cts_app domain in the policy with the requisite permissions. However, > as package names are arbitrary and there is no namespace control over > who can use what names, that would be less safe in practice - any third > party app could use the same name. That only really works for system > apps where you know that the package is pre-installed. > > -- > Stephen Smalley > National Security Agency > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
