SELinux context for init-script

[cjeanneret]

After many tests, it seems the init-script issue is due to SELinux context, NOT path as mentioned in #69.

In order to follow it, a new issue is created.

Here are the steps we tested on our own in order to debug this:

• Set init-script context to u:object_r:userinit_exec:s0 doesn't help (script doesn't even seem to be called)
• Set init-script context to u:r:init:s0 doesn't help (here again, script doesn't even seem to be called)
• "su" binary on CM12 comes from Superuser.apk, which doesn't support "--context" option
• Script doesn't find "su" binary at startup, even with an enforced PATH value
• We're able to run setenforce 0 on CM12 with default "su" binary
• We might want to push a custom SELinux policy in order to allow the init-script to run iptables commands
• Apparently, iptables should be run in "u:r:init:s0" context, as tested by @ahf
• this documentation might provide some hints: https://source.android.com/devices/tech/security/selinux/customize.html

What should the policy allow:

• run "iptables" binary in the "u:r:sysinit:s0" context
  This is apparently the only authorization we might need — unsure about that.

[cjeanneret]

Something like this might be a start:

type orwall;
permissive_or_unconfined(orwall)
type orwall_exec, exec_type, file_type;

allow orwall shell_exec:file rx_file_perms;
allow orwall system_file:file rx_file_perms;

Though I have some doubts. Really not a SELinux admin :(.

[ahf]

Our troubles:

type=2000 msg=audit(0.610:1): initialized
type=1403 msg=audit(691415.530:2): policy loaded auid=4294967295 ses=4294967295
type=1404 msg=audit(691415.550:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
type=1400 msg=audit(691423.780:4): avc:  denied  { create } for  uid=0 pid=391 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.780:5): avc:  denied  { create } for  uid=0 pid=391 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.820:6): avc:  denied  { create } for  uid=0 pid=402 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.820:7): avc:  denied  { create } for  uid=0 pid=402 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.930:8): avc:  denied  { create } for  uid=0 pid=416 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.930:9): avc:  denied  { create } for  uid=0 pid=416 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.970:10): avc:  denied  { create } for  uid=0 pid=425 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691423.970:11): avc:  denied  { create } for  uid=0 pid=425 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691424.030:12): avc:  denied  { create } for  uid=0 pid=432 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691424.090:13): avc:  denied  { create } for  uid=0 pid=436 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691424.090:14): avc:  denied  { create } for  uid=0 pid=436 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691424.130:15): avc:  denied  { create } for  uid=0 pid=443 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691424.130:16): avc:  denied  { create } for  uid=0 pid=443 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=0
type=1400 msg=audit(691424.170:17): avc:  denied  { create } for  uid=0 pid=451 comm="iptables" scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=1
type=1400 msg=audit(691424.170:18): avc:  denied  { net_raw } for  uid=0 pid=451 comm="iptables" capability=13  scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=capability permissive=1
type=1400 msg=audit(691424.170:19): avc:  denied  { getopt } for  uid=0 pid=451 comm="iptables" lport=255 scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=1
type=1400 msg=audit(691424.170:20): avc:  denied  { net_admin } for  uid=0 pid=451 comm="iptables" capability=12  scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=capability permissive=1
type=1400 msg=audit(691424.170:21): avc:  denied  { setopt } for  uid=0 pid=451 comm="iptables" lport=255 scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0 tclass=rawip_socket permissive=1
type=1400 msg=audit(691424.280:27): avc:  denied  { module_request } for  uid=0 pid=468 comm="ip6tables" kmod="ip6table_nat" scontext=u:r:sysinit:s0 tcontext=u:r:kernel:s0 tclass=system permissive=1

[ahf]

Odd that the permissive bit is changing during this.

[ahf]

I assume this is the policy that's loaded: https://android.googlesource.com/platform/external/sepolicy/+/master

[xeroxnir]

Deleted previous posts for a better solution. Using https://github.com/xmikos/setools-android/tree/master/jni/sepolicy-inject one can chang sysinit domain to permissive mode using command:
sepolicy-inject -Z sysinit -P /sepolicy -o /data/tmp/sepolicy. Rules can be updated by copying selinux_version file, sepolicy, *_contexts and /system/etc/security/mac_permissions.xml to /data/security/current/ folder and setting setprop selinux.reload_policy 1.

[DocSniper]

Yes, SELinux is the reason why /data/local/userinit.sh and /system/etc/init.d/90userinit aren't executed:

type=1400 msg=audit(797603.940:4): avc: denied { relabelfrom } for pid=1 comm="init" name="userinit.sh" dev="mmcblk0p35" ino=580015 scontext=u:r:init:s0 tcontext=u:object_r:userinit_exec:s0 tclass=file permissive=0

type=1400 msg=audit(1441975252.903:910): avc: denied { getattr } for pid=2918 comm="ostsq.commander" path="/system/etc/init.d/90userinit" dev="mmcblk0p30" ino=486 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:userinit_exec:s0 tclass=file permissive=0
type=1400 msg=audit(1441975252.903:911): avc: denied { getattr } for pid=2918 comm="ostsq.commander" path="/system/etc/init.d/90userinit" dev="mmcblk0p30" ino=486 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:userinit_exec:s0 tclass=file permissive=0
type=1400 msg=audit(1441975252.903:912): avc: denied { getattr } for pid=2918 comm="ostsq.commander" path="/system/etc/init.d/90userinit" dev="mmcblk0p30" ino=486 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:userinit_exec:s0 tclass=file permissive=0

[DocSniper]

I was able to set the correct SELinux rights to get userinit.sh executed

chcon u:object_r:userinit_exec:s0 /system/etc/init.d/90userinit
chcon u:object_r:userinit_data_exec:s0 /data/local/userinit.sh

[cjeanneret]

Heya!
thanks for the tip, I was thinking about that too, but due to some lack of time, I couldn't do it.
There's just a small problem: 90userinit and userinit.sh are actually system files (at least on CM12), hence their right will most probably be overridden with updates.

I'll try to find the time to set the context on our file instead of the userinit, though I'm pretty sure this won't work as expected… OrWall will need to check the script context and reset it — and then ask for a reboot. Humpf…

[DocSniper]

Glad I could help. :-)

But nevertheless, if you try to execute iptables via userinit.sh, it's execution is denied.

[cjeanneret]

Ah, so that's the same error I currently have… In fact, on my CM12, init-script is launched, but I get the denied described in the previous messages. It seems I could use a "su" option in order to enforce command context, but this means relying on a precise "su" APK, which is kind of ugly, especially when there are multiple "su" APK, each ROM having its favorite 😞

Thus, it's a bit annoying. I'll try to find some time in order to sort this issue, as it's really a show stopper: we can't trust our device, hence we have to lock down its communications as soon as possible (which is the goal of the init-script: just lock down connections, until orWall is started).

There are two ways:

• either use the su capability when available (but as said, ugly as hell)
• or add a SELinux policy, which is the best way — though also a bit complicated…

The second way being the best, I'll need to find out what to push in it, and how to push the policy in the system. I read some weeks (or was it months??) ago some docs about it, but I'm really short of time…

[c3ph3us]

http://selinuxproject.org/page/NB_SEforAndroid_1#Updating_Policy_Files

http://seandroid.bitbucket.org/AddressingHiddenDenials.html#13

[infinity0]

Hey, what's the status on this? Running the following in an adb root shell, then rebooting, appears to work for me on CM-13 (whose su does not have --context):

# cp /data/data/org.ethack.orwall/app_bin/userinit.sh /data/local
# chcon u:object_r:userinit_data_exec:s0 /data/local/userinit.sh

Apps not enabled in orwall don't get any internet access, and this persists even if I disable then enable orwall. However, orwall still says "iptables appears not to be initialised".

In other words, we don't actually need our su to have a --context option, we can just run chcon as root. Since orwall requires su already, this shouldn't be a problem, right?

[infinity0]

Ah sorry for the noise - I'm running into the same issues described above, with iptables being denied execution. I tried to change userinit.sh to use runcon instead:

IP6TABLES=/system/bin/runcon u:r:init:s0 /system/bin/ip6tables
IPTABLES=/system/bin/runcom u:r:init:s0 /system/bin/iptables

but this just gets ignored and my logs show that it's still being run as scontext=u:r:sysinit:s0 tcontext=u:r:sysinit:s0. This suggests that using su --context even if available, possibly wouldn't work anyway, since it typically just delegates to runcon - https://su.chainfire.eu/#selinux-contexts-switching-how - never mind the fact that superSU is closed source and could be sending all your data to whoever it wants.

I guess the behaviour I observed about apps getting blocked was just orwall working normally.

[isislovecruft]

Hey, I think I've gotten this working on device running Android 5.2.1.

The first thing I tried, which did not work was to do the following (on the device, or through an adb shell):

su
mount -o rw,remount /system
chcon u:object_r:userinit_exec:s0 /system/etc/init.d/90userinit
cp /data/data/org.ethack.orwall/app_bin/userinit.sh /data/local/userinit.sh
chcon u:object_t:userinit_data_exec:s0 /data/local/userinit.sh

This didn't seem to have any effect, but it seems wise to put it here, just in case the it did have some effect in combination with the things I tried on the second attempt. Doing the following (again, on the device) and then rebooting it seems to fix the issue:

su
mount -o rw,remount /system
mkdir /system/su.d
chmod 0700 /system/su.d
cp /etc/init.d/91firewall /system/su.d/

[ahf]

Cool!

Does /system/su.d/ init scripts run before/together with/after the regular /etc/init.d/ scripts?