search

phhusson / Superuser

Keeping koush's Superuser fresh
GNU General Public License v3.0
424 stars 50 forks source link

No neverallow breakage policy #17

Open phhusson opened 8 years ago

phhusson commented 8 years ago

Something that could be great would be a specific policy which doesn't break any neverallow, and would actually be able to pass CTS (except for the explicit check of "su" binary) This would obviously make this su not as useful or powerful, but I believe this could trigger interesting discussions either on Google's side or manufacturer's side. Possibly it would make Google update neverallow to harder policies, but I doubt they would add neverallow rules "just to piss of SU guys"

lbdroid commented 8 years ago

I've been thinking about this myself, and even added an issue to my side about that.

The angle I was thinking, was to make the su domain into something that would allow you to transition through it. I.e., if you could transition from su into anything, then would su actually need to be allowed to do anything else? It would make use of su more complicated, since you would either have to always specify the target context, or it would have to somehow detect the required context and transition itself. The latter would require a "try twice" approach though, since the target resource context is usually not immediately apparent, so you would have to check the audit log and try again.

lbdroid commented 8 years ago

I don't think that it is particularly important to worry about passing the "don't alter any neverallow" rule of CTS. Our whole objective is a violation of CTS by definition. Specifically, section 9.4: "Alternate Execution Environments.... MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or any other user ID."

phhusson commented 8 years ago

Ok, good, then I know exactly what we can do: su ALWAYS setuid back to original's UID, but su would be used only to gain capabilities.

phhusson commented 8 years ago

neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute; libsepol.report_failure: neverallow violated by allow su dalvikcache_data_file:file { execute };

This one is really annoying. I guess I can add "su" in "appdomain", but I'm afraid I'll hit more problems. Perhaps I can add a su_appdomain context, with autotransition when calling app_process... :/

junit.framework.AssertionFailedError: The following errors were encountered when validating the SELinuxneverallow rule: neverallow domain { file_type -exec_type }:file entrypoint;

libsepol.report_failure: neverallow violated by allow su dalvikcache_data_file:file { entrypoint }; This should be easy to fix, it is just due to a misplaced wildcard.

neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace; libsepol.report_failure: neverallow violated by allow su_daemon su_daemon:capability { sys_ptrace }; This can be fixed by removing from_init() (which causes me a lot of headaches for various policy reasons)

And android.cts.security.SELinuxHostTest#testSuDomain will fail if there is a su shell running (but it's fine right after reboot, since su daemon is running su_daemon)