On 04/25/2014 12:05 PM, pragma wrote: > Thanks again for the excellent response. > > I received a report of the failure from a user out in the field, and I > have actually not yet reproduced it personally since I've refrained > from upgrading Android on my device because I am a heavy user > of root apps and am leery of SEAndroid breaking my tools. But > I suppose it's time to bite that bullet and learn how to work with > SEAndroid policies. > > I am somewhat concerned about the ramifications of using > sepolicy-inject on an end-user's device. I could display a dialog > explaining that I intend to update their SEAndroid policy to allow > executing a binary from the /data folder and only continue if they > explicitly confirm the action. I will have to learn how to do this > so that only the nflog binary belonging to the app is allowed > rather than allowing all binaries in /data to be executed. As > I said, it's time for me to get with the times and learn about > SEAndroid!
So, a couple of observations and a pointer: - I think you'll find it much easier to just install your helper to /system rather than trying to modify the policy on the device. If however you truly want to chase down this path... - sepolicy-inject will just let you generate a modified kernel policy file with your additional rule. You still need some way of loading it into the kernel. The officially supported way is to write it to one of the supported policy file locations and then do a setprop selinux.reload_policy 1 to trigger a reload by init. In current Android releases, the officially supported location for policy updates is /data/security/current/sepolicy (the original policy is loaded from /sepolicy, but you obviously cannot persistently change that without regenerating the boot image and reflashing it). On Samsung devices though I think they are still using /data/security/sepolicy (the original, pre-4.3 location), not /data/security/current/sepolicy (Google moved the files to a subdirectory in AOSP 4.3 release for use by their SELinuxPolicyInstallReceiver). Whether or not that mechanism will still work in the future is unclear; it was recently reverted in AOSP master due to some problems with respect to incompatibility between policy updates installed this way and OTAs. We have a set of patches uploaded to AOSP to try to introduce a version checking mechanism to resolve this. - To truly limit what can be executed from /data would require your app to be labeled differently than other apps, which would require modifying not only sepolicy but also mac_permissions.xml and seapp_contexts so that its /data/data files are labeled with a distinct type that can then be made executable by the su daemon process. I'll be giving a talk at the Android Builders Summit next week that may be helpful; the slides are already available from: http://events.linuxfoundation.org/events/android-builders-summit/program/slides _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
