Root privileges, don't forget the SELinux

The following example runs on the ZTE Android 5.0 phone.

When we use the root-privileged python to create the socket listener Port 8088, SELinux outputs the following record to the Kmsg

PYTHON-ANDROID5 the operation of the socket create, setopt, bind, listen, etc. are denied disallowed, because the target requires permission in Tcontext=u:r:init:s0, But our Python runs under root, so scontext=u:r:init:s0 satisfies the tcontext, our operation is allowed permissive=1, but not what the SELinux subsystem wants, and is recorded in Kmsg.

Since we have successfully monitored on port 8088, is it equivalent to receiving incoming connections, perhaps you would think of firewall filtering, and we would look at the firewall policy (port 8088 is released).

So what happens if we initiate a connection to the listening port 8088 that we opened above? If the result fails, look at the kmsg output.

Firewall netd to Scontext=u:r:netd:s0, should be want to port 8088 socket backlog write, but helpless operation socket need permission Tcontext=u:r:init:s0, The firewall operation for listen Sokcet {Read Write} was rejected by the SELinux subsystem permissive=0,selinux to kmsg output log records. The firewall is not running under high authority, and even if your program is elevated to root, there is nothing you can do about it. In other words, if your program relies on the services of other processes, the SELinux permissions of the processes you rely on will also constrain your program. Then we had to close selinux, but it was less secure.

After we shut down SELinux, we started the connection to Port 8088 again, and the results were successful, looking at the kmsg output.

First of all, our Python program created a socket under root privileges, and the firewall netd with no permissions also with the SELinux subsystem shutdown, the operation of the socket is allowed, all of which is not desired by the SELinux subsystem, must be recorded in the Kmsg log. The following is the normal TCP to establish a connection three times handshake, SELinux also recorded in kmsg log, the log output is as follows.

Another example is screencap, you can not under the root permission to intercept the screen.

SELinux outputs records in kmsg.

The solution is to turn SELinux off, via Setenforce or/sys/fs/selinux. This is not safe, and the other is to use Supolicy to modify individual policies.

Root privileges, don't forget the SELinux