Tethering (WIFI/USB) not working without "applications running as root" rule #4

Closed
CHEF-KOCH opened this Issue Oct 28, 2012 · 16 comments

Projects

None yet

5 participants

@CHEF-KOCH
Contributor
  • Start a WIFI- or USB-Tethering session
  • Open a Browser e.g. stock browser or any other and go to any url
  • Noting happens

What is the expected output? What do you see instead?
Without manually setting a rule it should work instantly.

Solution:
Go into AFWALL+ and tick "applications running as root", after that the connection seems to work correct.

@ukanth ukanth was assigned Oct 28, 2012
@ukanth
Owner
ukanth commented Dec 29, 2012

Ok, found an easy way to implement this. It'll be another mode like whitelist/blacklist.

-> Tether Mode
-> Local host Mode

etc.,

@gentoolkit

I am running Cyanogenmod 10.1 on my Samsung Galaxy Note 2 (N7100). I am unable to use the WIFI tethering when AFWall (1.2.3) is enabled. I am using the White list mode and I have only disabled few 3rd party apps which are not related to the tethering. Applications running as root can access the internet. Deactivating the firewall and flushing the rules makes the tethering work again.

@SuhyX
SuhyX commented Apr 24, 2013

i'm on mackey rom 4.2.2 which is CM10.1 based, and just tried latest AFwall+ (1.2.4.1), and the problem is still here.. tethering over wifi not working.
i think afwall+ blocks dns requests ! if i ping with ip i get answare, but if i ping with name, no response..

@cernekee
Contributor
cernekee commented May 5, 2013

This may vary based on the tethering app or ROM, but try adding custom rules to allow DHCP and DNS through:

$IPTABLES -A afwall-wifi -m owner --uid-owner 0 -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner 0 -p udp --sport=53 -j RETURN

If it doesn't work, I would suggest enabling logging and posting the output.

Obviously, any other app with root privileges can just change the iptables rules if it REALLY wants to talk to the network...

@gentoolkit

I tried the custom rules you give. They did not help. As noted above, it appears that the DNS traffic is somehow blocked. I also tried the following:

$IPTABLES -A afwall-wifi -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -p udp --sport=53 -j RETURN

However, they too did not work.

I enabled the logging. Here is the output:

AppID: -1
Application Name:
Total Packets Blocked: 47
***.***.***.*** <- Ip which seems to be located to my operators network. DNS server?
***.***.***.*** <- My second device
@cernekee
Contributor
cernekee commented May 5, 2013

What if you also enable root access to 3G, but not wifi?

Maybe we also need: $IPTABLES -A afwall-3g -m owner --uid-owner 0 -p udp --dport=53 -j RETURN

(Come to think of it I'm not sure why my test setup worked without it. Will need to investigate.)

Do you know if DNS forwarding is being handled by dnsmasq on your device?

@gentoolkit

"(root) Applications running as root" already have access to both WLAN and 3G.

I tried the following:

$IPTABLES -A afwall-wifi -m owner --uid-owner 0 -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner 0 -p udp --sport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner 0 -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner 0 -p udp --sport=53 -j RETURN

DNS is still blocked. However, the logs do not show my second device's IP address anymore. Only the (assumed) DNS server IP address is getting blocked. And now it seems that flushing is no longer necessary. Disabling the firewall is enough make the tethering work again.

I guess that the Cyanogenmod is using the stock Android WLAN tethering. However, I am not sure how it works exactly. How can I check whether dnsmasq is in use? I know that there is dnsmasq installed on the device.

@gentoolkit

I just realized that I commented on the wrong bug report. Should I open a new bug report? As I stated above, enabling "applications running as root" to access the Internet does not help so this is probably the wrong place to talk about my tethering problem.

@cernekee
Contributor
cernekee commented May 5, 2013

On CM10.1 I see that dnsmasq is running as nobody (uid 9999) instead of root (uid 0). Could you try changing the rules to use "--uid-owner nobody" or "--uid-owner 9999"?

@gentoolkit

I tried:

$IPTABLES -A afwall-wifi -m owner --uid-owner 9999 -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner 9999 -p udp --sport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner 9999 -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner 9999 -p udp --sport=53 -j RETURN

and

$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -p udp --sport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner nobody -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner nobody -p udp --sport=53 -j RETURN

DNS is still getting blocked.

@gentoolkit

This works:

$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner nobody -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner nobody -j RETURN

Thank you for your help!

@cernekee
Contributor
cernekee commented May 5, 2013

This works:

Good news - but if you don't mind, we can try making the rules a little tighter:

$IPTABLES -A afwall-3g -m owner --uid-owner nobody -p udp --sport=67 --dport=68 -j RETURN

Source port 67, dest port 68 is for dnsmasq's DHCP server. DHCP should only be needed on the wifi side, so this line can be omitted entirely.

$IPTABLES -A afwall-3g -m owner --uid-owner nobody -p udp --sport=53 -j RETURN

On the 3G side, we should use --dport=53 as these are outbound DNS requests.

Also, since some devices run dnsmasq as root, and since some DNS transactions use TCP, we'll add rules to cover those cases. So the full set of rules is:

$IPTABLES -A afwall-wifi -m owner --uid-owner root -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -p udp --sport=67 --dport=68 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner root -p udp --sport=53 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -p udp --sport=53 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner root -p tcp --sport=53 -j RETURN
$IPTABLES -A afwall-wifi -m owner --uid-owner nobody -p tcp --sport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner root -p udp --dport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner nobody -p udp --dport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner root -p tcp --dport=53 -j RETURN
$IPTABLES -A afwall-3g -m owner --uid-owner nobody -p tcp --dport=53 -j RETURN

Some other random musings:

Maybe it would be best to just allow all traffic from the dnsmasq process. Some versions of iptables have a --cmd-owner flag, but this is probably unsafe because any process can create another process named "dnsmasq" to trick us. Is there a better way to do this (without asking all ROMs to run dnsmasq under a well-known uid)?

I wonder what else might be allowed to run as the "nobody" user?

It would be worth checking to see if "-m multiport --sports x,y,z" is supported on all devices.

Ideally these rules would be created/removed in response to tether enable/disable - not kept active all of the time. This prevents them from opening up any new holes when wifi is used to access the internet. I'm looking at ConnectivityChangeReceiver to see if it could be tweaked to do this. We can't get the tethering state directly from NetworkInfo, but it is obtainable via hidden APIs:

http://stackoverflow.com/questions/9065592/how-to-detect-wifi-tethering-state
http://stackoverflow.com/questions/14680978/monitoring-the-hotspot-state-in-android

Another reason for the app to start monitoring wifi connection changes is to figure out when the LAN subnet and mask change. This may be necessary to effectively allow/disallow LAN access on a per-application basis, one of the outstanding items on the TODO list.

Side question for ukanth: I see how this handles the transition from "not roaming" to "roaming", but does it ever reapply the rules when transitioning from "roaming" to "not roaming"?

       public void onReceive(final Context context, Intent intent) {
                try {

                        ConnectivityManager cm = (ConnectivityManager) context
                                        .getSystemService(Context.CONNECTIVITY_SERVICE);
                        NetworkInfo[] ni = cm.getAllNetworkInfo();
                        for (NetworkInfo info : ni) {
                                if (ni != null) {
                                        if (info.getType() == ConnectivityManager.TYPE_MOBILE)
                                                if (info.isConnectedOrConnecting() && info.isRoaming()) {
                                                        Api.applyIptablesRules(context, false);
                                                }
                                }
                        }
@gentoolkit

These tighter rules you provided seem to work as well.

@cernekee cernekee added a commit to cernekee/afwall that referenced this issue May 5, 2013
@cernekee cernekee ukanth/afwall#4: Add new (Tethering) special uid to create dnsmasq DH…
…CP + DNS rules
d3fb767
@cernekee cernekee added a commit to cernekee/afwall that referenced this issue May 5, 2013
@cernekee cernekee ukanth/afwall#4: Use new addRuleForUser() helper to simplify dhcp/wif…
…i code
73e91be
@cernekee
Contributor
cernekee commented May 5, 2013

I have submitted patches that add a "(Tethering)" option to handle this case:

Screenshot: https://www.dropbox.com/s/at87kbkdws4ju5c/tether-screenshot.png
Prebuilt APK: https://www.dropbox.com/s/8nyd72jh4c5fzbq/AFWall.apk

This APK is not signed with ukanth's key so you would need to export your rules, uninstall the original AFWall+, run "adb install -r AFWall.apk", then re-import your rules and fix all preferences. (Sorry.)

BTW if you scroll rapidly up and down through the application list, do you notice some of the system apps changing between red and white?

@ukanth
Owner
ukanth commented May 6, 2013

cernekee, thanks for the patches. I'll go through the discussion and merge the changes.

@gentoolkit

The prebuild APK you provided works as intended. Thank you. I have not noticed that the system apps would change between red and white.

@cernekee cernekee added a commit to cernekee/afwall that referenced this issue May 12, 2013
@cernekee cernekee ukanth/afwall#4: Add new (Tethering) special uid to create dnsmasq DH…
…CP + DNS rules
5e699a1
@cernekee cernekee added a commit to cernekee/afwall that referenced this issue May 12, 2013
@cernekee cernekee ukanth/afwall#4: Use new addRuleForUser() helper to simplify dhcp/wif…
…i code
ee52023
@ukanth ukanth closed this Mar 18, 2014
@cernekee cernekee changed the title from Thetering (WIFI/USB) not working without "applications running as root" rule to Tethering (WIFI/USB) not working without "applications running as root" rule Jul 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment