You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unknown number of projects may require such changes,
Such policy changes always introduce some security compromise by definition, even if not serious.
Potential for two or more policy changes working together to create an unexpected significant hole in security.
Causes harm through weakening of selinux policy to end users who don't need those compromises.
Requires maintenance on THIS end.
Solution;
Have a list of custom policy changes required by end-users.
Read that list during execution of this update package.
Append them.
Might be appropriate to use the Superuser android application for maintenance of this list, having an appropriate intent for end user application to call in order to add policy change, and requiring user-authentication to complete the request. Superuser application can periodically check the installed applications to verify that all those with current policy changes are still installed, clear out policy changes for removed applications. It is also possible for Superuser application to initiate a reboot and update cycle.
Thanks for opening a bug. Much better than talking on an unrelated thread.
(The change specific for that app isn't a security threat as mentioned in the commit)
The thing is devs don't know anything about SELinux. But there aren't that many different use cases.
At the moment my superuser.zip has different settings, changeable via config.txt in the superuser.zip
It has very few settings ((no)verity, (no)crypt, "user" or "eng" target). But can be extended.
I do believe all relevant selinux policies should be included this repo and supported, because if it's not supported, noone will try to deal with SELinux and will just run permissive.
I'm just unsure as to how it should be supported. There is the "eng" vs "user" version I currently. Or there could be a "tag-based" policy (a firewall tag, an audio tag, etc. and users have to chose a minimum)
eng/user pros are that it makes more sense for build bot, it is much easier to maintain for few people.
Its cons are the one you mentioned, user A's security suffers from the use of user B of dangerous apps.
tag-based is safer for serious users, but harder to maintain (there will be redundancies, one has to test every combination), and probably most users will just tick everything.
Some projects, i.e. http://forum.xda-developers.com/nexus-6/themes-apps/viper4android-t2952137 require ability to add persistent changes to sepolicy. While it is certainly possible to add workarounds for specific projects in an as-needed basis, such as 213b4d9 , this solution is not sustainable long term.
Reasons;
Solution;
Have a list of custom policy changes required by end-users.
Read that list during execution of this update package.
Append them.
Might be appropriate to use the Superuser android application for maintenance of this list, having an appropriate intent for end user application to call in order to add policy change, and requiring user-authentication to complete the request. Superuser application can periodically check the installed applications to verify that all those with current policy changes are still installed, clear out policy changes for removed applications. It is also possible for Superuser application to initiate a reboot and update cycle.
http://android.stackexchange.com/questions/67622/shell-script-to-reboot-into-recovery-and-install-zip
The text was updated successfully, but these errors were encountered: