The 00-devmode-firewall.conf does not apply

General
#1

I have modified this config file, daemon-reload and connman restart but these rules has not been applied

~]# cat /etc/connman/firewall.d/00-devmode-firewall.conf
[wifi]

# In developer mode allow to connect over SSH over wifi
# with IPv4. With IPv6 SSH port is open because of the -m
# switch problems in connman iptables. The IPv6 rule for
# accepting SSH in WiFi is retained for future use.

IPv4.INPUT.RULES = -p tcp -m tcp --dport 22 -j DROP
IPv6.INPUT.RULES = -p tcp -m tcp --dport 22 -j DROP

[tether]

IPv4.INPUT.RULES = -p tcp -m tcp --dport 22 -j DROP
IPv6.INPUT.RULES = -p tcp -m tcp --dport 22 -j DROP

[ethernet]

# Similarly for ethernet allow SSH over it when connected.
IPv4.INPUT.RULES = -p tcp -m tcp --dport 22 -j ACCEPT
IPv6.INPUT.RULES = -p tcp -m tcp --dport 22 -j ACCEPT
#2

I found out way. The wifi and ethernet sections are just descriptive not functional. In fact, iptables -S shows that there are no chains and the experience tech me that the labels are not referring to the interfaces which are wlan0, tether and rndis0.

The only section which is functional is [General]. It is fine, no problem because I can decide which interface is involved by iptables parameters and after all there are difference between input and output on the same interface.

Unfortunately, renaming or adding a new file in /etc/connman/firewall.d, it will be ignored. Despite daemon-reload and restart of the connman service. This is a quite surprinse for me and in bad way. Possibly, there is a list of activation: files that are loaded but the folder.d principle is not about having an activation list or a limited set of files.

Can someone tell me something about this?

In the meantime I have released the v0.0.5 of the patch that uses and thus alter connman firewall.

After many days and reboots (because GPS testing), it is ready to be adopted / tested by end-users as well.

#3
#4

from that page, I found this which is very intersting for me:

and after some turns to this one:

in particular this one:

in which this is crazy because force us to use infinitely long lines instead of multiple lines with all the craziness^2 when a patch is needed to be created.

Rules are separated with semicolons (;). All rules for a key must be on one line.

In fact the first consequence of this crazy syntax is immediate:

Rules can be commented out with hash tag (#) as first character. Commented rules
are simply ignored. For example:

IPv4.INPUT.RULES = #-p udp -m udp --dport 23 -j ACCEPT; -p udp -m udp --dport 24 -j ACCEPT

Will discard the first --dport 23 rule and use the second --dport 24 rule

Impose this restriction to the admins / users makes no sense expecially considering that

[General]

IPv4.INPUT.RULES = rule1
#IPv4.INPUT.RULES = rule2
IPv4.INPUT.RULES = rule3

can be easily parsed with

  • removes the commented lines
  • join all the remaining rules into the section per chain-name

Which means having a simple reg-expression pre-parser to make admin / users comfortable.

Secondly, also the rest of “The most notable exceptions” makes little sense for me because after all, it is just a matter to pass those instructions to iptables. Probably the connman should understand such a rules in some kind of ways. Therefore, I suspend my judgment.

Finally, we are on the point that I am caring about:

For this, for example following rules could be enabled to allow only DHCP and
DNS, into, e.g., /etc/connman/firewall.d/42-tethering-firewall.conf

In particular that files does not exist by default:

~]# ls -al /etc/connman/firewall.d/42-tethering-firewall.conf
ls: /etc/connman/firewall.d/42-tethering-firewall.conf: No such file or directory

creating or renaming one existing file would make that new file ignored. So, I decided to following the instructions exactly how they are proposed and surprinsingly (for me, now) it works even if I rename 42 with 12.

THE MISTAKE

The initial mistake was using -i tether into rule for [tethering], that’s all. Again, this hell could have been avoided in first place if a sanitizing regular expressions engine would elaborate the config files before being passed to connman. It would have removed -i tether because redundant and evidently inherited by the iptables rule used for testing, if found into [tethering] section, otherwise log an error and removed the rule (resilience) but not fail-over about the entire file (fragility).

4 Likes
A collection of tasks and a request for changes