Thanks. I noticed that all my 3 Android apps require internet access … but if nothing else, it’s nice to get a list.
The privilege escalation for editing the config is very jarring btw.
The app must restart itself as root to edit the configuration. It’s not ideal but it works…
Looks like it works now )
1 Like
You can have a privileged daemon that can edit those files and then call it from your main app using polkit for auth, that’s what I do for AAS Installer Patcher.
1 Like
Ah, that’s a neat trick, and a big improvement over how I did it. I’d tried using “reload” after updating the config file & wondered why it didn’t take effect.
1 Like
I think I’d prefer a whitelist approach, i.e. all Android apps are blocked by default, and one would punch holes for certain apps.
I tried to achieve this with a config file analogous to what your script does, but it just doesn’t work:
root@Xperia10II-DualSIM:/etc/connman/firewall.d
> cat 61-block-all-appsupport.conf
## Reject all appsupport user IDs, starting with 500 000 (appsupport-root)
## Maximum:
## It's probably 2^32 (4 billion). On RHEL UID 4,294,967,295 (2^32-1) is often reserved for an "invalid value" UID
## and 4,294,967,294 (2^32-2) is reserved for the nfsnobody user in some operating systems.
## see comments for https://serverfault.com/q/105260
## The below is the maximum iptables would accept:
[General]
IPv4.OUTPUT.RULES = -m owner --uid-owner 500000-4294967294 -j REJECT ;
IPv6.OUTPUT.RULES = -m owner --uid-owner 500000-4294967294 -j REJECT ;
I tried renaming the file between 60-something.conf and 61-something.conf, I tried systemctl reload connman and systemctl restart connman, I tried replacing the range with a single user ID, I even tried removing the comments.
Even after a reboot that rule does not take, but your rules (created through the app) do.
I’m testing this both through iptables -L and through firing up Android apps.
When applied manually like this:
iptables -A connman-OUTPUT -v -m owner --uid-owner 500000-4294967294 -j REJECT
it works perfectly, each time.
What am I doing wrong?
1 Like
I tried what to do what you wanted, and it worked for me:
[root@Xperia10III defaultuser]# cat /etc/connman/firewall.d/60-block-android-apps-firewall.conf
[General]
IPv4.OUTPUT.RULES = -m owner --uid-owner 500000-4294967294 -j REJECT ;
IPv6.OUTPUT.RULES = -m owner --uid-owner 500000-4294967294 -j REJECT ;
[root@Xperia10III defaultuser]# systemctl restart connman
[root@Xperia10III defaultuser]# iptables -nL connman-OUTPUT --line-numbers
Chain connman-OUTPUT (1 references)
num target prot opt source destination
1 ACCEPT 1 -- 0.0.0.0/0 0.0.0.0/0 icmp !type 0 code 0
2 REJECT 0 -- 0.0.0.0/0 0.0.0.0/0 owner UID match 500000-4294967294 reject-with icmp-port-unreachable
I can use iptables to check that ConnMan has updated the firewall. If it’s not working for you, then something must be different. One thing I notice is that your file doesn’t end in -firewall.conf… and indeed, if I rename the file to 60-block-android-apps.conf then it no-longer works.
I haven’t yet been able to get this to work. Simply renaming the file & then reloading connman causes my firewall rules to stop working entirely (unless I restart connman or rename it back). It’s very weird.
That was it. Thank you!
This seems to sometimes work, sometimes not, sometimes have the opposite effect: it removes the rule. Even trying new numbers like 62- etc doesn’t help. After a dozen tries or so I can see no pattern in this; systemctl restart works however.
Isn’t it enough (until reboot) to apply the rule in question manually via iptables command?
After a reboot the config files do their job.
Thanks for confirming I’m not entirely mad! Yes, restart works perfectly, just rather slowly.
Yes, but it’s just a bit of a kludge, and in theory has the risks bugs (so I understand why ichthyosaurus didn’t want to do it)… but it works for me, so I am happy until someone reports it doesn’t work for them.
I’ve mostly rewritten my script to offer the option of blocking all Android apps (except for the ones you list), however once ConnMan is restarted the firewall starts blocking everything (even though the block-all rule is still the last one).
If you can get your idea of blocking everything except certain Android apps to work after restarting ConnMan, please let me know how you achieved it…
1 Like
I think I’ve solved it. The problem was the silly UID range we were giving to iptables (which also gradually broke Sailfish OS - I eventually had to reboot). It seems to work when using the actual range of UIDs used for user applications, which is 510000-519999.
I’ve updated my script to optionally allow blocking all Android apps except those you’ve allowed:
FirewallAndroidApps.zip
It’s had even less testing than before, but it seems to work for me. Please let me know if you notice any bugs!
2 Likes
That was quick, amazing. Thanks I guess! I’ll check it out immediately.
Sorry why would this be a kludge? Seems perfectly valid to me; that’s how iptables is supposed to be used. You still add the config file which should work on service restarts etc. Anyhow, connman behaving erratically (I’ve encountered this before btw) is the problem.
And @ichthyosaurus, what was your reasoning?
Can you clarify? How did it “break” the OS? I haven’t noticed anything. There’s nothing silly about that range, which I took a long time to look up:
- User appsupport-root is 500 000, so it makes sense to start with that. And I think we can be sure that Android accesses the internet by other means (user IDs) than just through user apps.
- I could not find out if appsupport puts a maximum on user IDs - I could for Android itself, but the info was contradicting, and I suspect appsupport uses different ranges anyhow. I’d be interested to know how you arrived at that specific range.
Granted, 4billion-1 is probably overkill; it’s the maximum possible for Linux itself (see tehnicaorg’s comment for https://serverfault.com/a/105265).
I thought it was a good idea, that I might use myself, and didn’t sound too hard to add - otherwise I might not have added it!
First SSH (not Terminal) stopped responding for random periods (becoming longer & more frequent) as if it was queuing my key presses over the network. And then I noticed that edge swipes weren’t working, so I couldn’t leave the current app.
Mainly it’s the parsing of the output of iptables, to determine which rules to delete - which is basically what ichthyosaurus said he didn’t want to do.
I’m reasonably confident it’s robust, and I’ve tried to err on the side of not deleting firewall rules if they don’t match exactly. So I’m reasonably happy about doing this.
I am being cautious, and only blocking network access done directly by the Android apps - I do not want to block other network stuff by Android OS, as that could have bad/unexpected consequences.
I don’t mind that Android does network stuff itself (on behalf of apps) such as retrieving AGPS data for quicker GPS locks, etc. Those kind of things are carefully limited by Android OS, and so should be pretty safe unless you are completely paranoid about privacy (in which case using Android apps may be a bad idea). I am happy with this compromise.
A quick Google search showed that UIDs 10000-19999 are reserved by Android for user-installed apps. AppSupport appears to start at 510000 for user apps, so I assumed it’s the same as Android but just shifted, thus 510000-519999.
Anything outside that range could have unexpected consequences (blocking more than just apps), and so IMHO that should be handled by a separate firewall rule file (if you want to be that extreme).
Also blocking the full 32-bit range seemed to overload part of Sailfish OS (not sure if it was just networking or also CPU/RAM), and each time I restarted ConnMan the problem got slightly worse. That’s not an acceptable risk/consequence to me.
OK, there’s a difference in philosophy here.
I don’t mean to sound demanding, but it would be great if that, too, could be a configurable option.
I’ll take another look at your script later.
All of course in the hope that @ichthyosaurus will eventually pick it up for his GUI version.
I have noticed that some network-related things break with that “silly” range; setting the max to something like 999999 seems to fix it, but I don’t like blindly guessing.
I’ll take a look inside appsupport (although it’s proprietary, not all of it is closed source) if I can find some hints.
Yeah, I am more interested in security than privacy (as long as I can stop apps from uploading my data to their creators). And not breaking things that my script doesn’t actually show in it’s list for the user to block/unblock (which would be very unexpected for most users).
There’s really no need for me to do that, because you can achieve exactly the same thing by adding an extra firewall config file - that you can then manually fiddle with if you find it causes any problems. All I need to do is prevent my script from deleting those rules - which I’ll do this evening.
Yes, I very much hope he will (as well as changing how the app refreshes the firewall, as I suspect it doesn’t work reliably - see our earlier discussion). I’m likely to switch to it eventually, but I have no urgency until I get my new Jolla phone & start using Sailfish OS as my main phone. Also I’m new to OpenRepos, and it’ll take me a while to decide what is safe to install & what might not be (as security is my primary concern), and installing random unverified apps off the internet is not the Linux way (well unless you run Arch & use the AUR!).
I see my script as an easy way to test-out (or ‘prototype’) new ideas for an Android firewall. Maybe eventually I’m learn enough to contribute directly to his app…
True. Say, this has to be the last rule then? My config file must start with a higher number than 60- or 61- or whatever your script uses?
I think I figured out the max user id value.
The lowest is APPSUPPORT_BASE_UID=$(appsupport-config --get-prop ro.alien.unprivileged_uid)
This should return 500 000 in all cases.
Then, LXC limits the range of mapped user/group ids via idmap.
According to /opt/appsupport/init/prepare-hook.d/75-generate-privilege-config.sh: MAX_UIDS=200000
The results can be seen in /tmp/appsupport/defaultuser/20-privilege_config.
Common sense says that a range of 500000-700000 is absolutely enough.
Or 510000-600000 and 610000-700000 for apps only, but that’s me guessing again based on the generated 20-privilege_config.
I’ve updated my script again:
FirewallAndroidApps.zip
It now includes an optional firewall file 69-block-android-system-firewall.conf to completely block AppSupport’s Android OS internet access, apart from the user-installed apps that you manage with the FirewallAndroidApps.sh script as usual. The script has been updated to be compatible with this firewall file.
As I have not tested the firewall file’s impact on AppSupport, nor long-term use on Sailfish OS, mild warnings against it’s use(!) are included in the file itself, along with installation instructions. Don’t say you weren’t warned!
With the way I have created the firewall rules, it can be any number. However I chose a much later number to (a) ensure that it doesn’t clash with any future changes to ichthyosaurus’s app, and (b) still have the same first digit so it’s clearly still related to the other firewall files.
Thanks for the description of how you arrived at the UID range. I haven’t looked into it myself, and have just used your UID range in the firewall file.
@chr1s @ohnonot I only skimmed your posts, and I hope I’ll find time to read them properly and to update the app this weekend.
Just a quick question: did you have issues with the config files created by my app, or only with the ones you were manually experimenting on? If so, how exactly did the firewall break for you? How did you notice / how can I check it on my phone? Because I haven’t noticed any issues on my side yet.
By the way, config files must be named xxx-firewall.config, otherwise they are ignored: Firewall | Sailfish OS Documentation
I’d like to keep compatibility with @chr1s’s script, so maybe I could add an option to generate the more restrictive/intrusive config too.
I also want to implement @Rikudou_Sennin’s authorization method but that’ll take some time too. I’m not happy with the current root starter; this would be a big improvement…
2 Likes