On Thu, Jan 24, 2013 at 5:39 PM, William Roberts <[email protected]>wrote:
> On Thu, Jan 24, 2013 at 1:43 PM, Stephen Smalley <[email protected]> > wrote: > > On 01/24/2013 04:37 PM, William Roberts wrote: > >> > >> I have a set of patches to come out after my current changes are > >> accepted that will remove system_app from being able to manage mmac > >> and selinux. > >> > >> Instead seapp contexts will move the seandroid manager package to > >> mac_manage domain, where it will have permission. > >> > >> Any objections / comments? > > > > > > If you plan to use the device admin APIs, then you can get rid of > > SEAndroidManager altogether and remove access for all app domains, > because > > then the changes are made by the DevicePolicyManager inside the > > system_server in response to API invocations from device admin apps. > > SEAndroidAdmin is a sample device admin app. > > > > Don't really want to break SEAndroidManager, that's a handy apk until > the device admin api's are pulled by Google. Also, if OEMs start to > use this, they may need to update policy in the same mechanism as > SEAndroidManager, so having a management domain ready to go, they can > add their app to is probably a good idea. They can just replace > seapp_contexts. > > I really think we should start moving away from the SEAndroidManager app altogether and instead rely on the functionality of the SEAndroidAdmin app. Anything that can be done with the SEAndroidManager app can also be done with the SEAndroidAdmin app (minus displaying denials). The coexistence of both the SEAndroidManager app and active SEAndroidAdmins can and will cause some weird policy enforcing states that have already been witnessed. Having two apps toggle the same system states independent of each other is an issue during boot, not to mention the complexity that can arise if we also put certain commands in the init.rc. For instance, moving from enforcing to permissive then back to enforcing has already been seen. In other cases expected enforcement states are toggled the other way during a reboot and left in the unexpected state after the boot completes. Solutions to some of these issues are being addressed but at the expense of code complexity and manageability. If we're waiting for the device admin stuff to be pulled, let alone reviewed, to start the transition it might be awhile. > > > >> I am initiating pull requests to the seandroid repos until our backlog > >> at AOSP is cleared out, any objections on that? > > > > > > That's fine. > > > > > > -- > 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] > the words "unsubscribe seandroid-list" without quotes as the message. >
