New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 participants
@CHEF-KOCH
Copy link
Contributor

CHEF-KOCH commented Oct 28, 2012

  • 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.

@ghost ghost assigned ukanth Oct 28, 2012

@ukanth

This comment has been minimized.

Copy link
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.,

@ghost

This comment has been minimized.

Copy link

ghost commented Apr 20, 2013

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
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...

@ghost

This comment has been minimized.

Copy link

ghost commented May 5, 2013

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

This comment has been minimized.

Copy link
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?

@ghost

This comment has been minimized.

Copy link

ghost commented May 5, 2013

"(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.

@ghost

This comment has been minimized.

Copy link

ghost commented May 5, 2013

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

This comment has been minimized.

Copy link
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"?

@ghost

This comment has been minimized.

Copy link

ghost commented May 5, 2013

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.

@ghost

This comment has been minimized.

Copy link

ghost commented May 5, 2013

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

This comment has been minimized.

Copy link
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);
                                                }
                                }
                        }
@ghost

This comment has been minimized.

Copy link

ghost commented May 5, 2013

These tighter rules you provided seem to work as well.

cernekee added a commit to cernekee/afwall that referenced this issue May 5, 2013

@cernekee

This comment has been minimized.

Copy link
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

This comment has been minimized.

Copy link
Owner

ukanth commented May 6, 2013

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

@ghost

This comment has been minimized.

Copy link

ghost commented May 8, 2013

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 added a commit to cernekee/afwall that referenced this issue May 12, 2013

@ukanth ukanth closed this Mar 18, 2014

@cernekee cernekee changed the title Thetering (WIFI/USB) not working without "applications running as root" rule 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