Is it possible for other apps to leverage AFwall+ as an iptables API?

[patcon]

New to android development, and trying to wrap my head around intents. Browsing the code, I'm unsure whether something like this is implemented.

Thanks!

[patcon]

Look through Api.java, thinking the simplest way to get full-featured support would be to expose some of the import functionality? Well, if nothing else is exposed, that is :)

[patcon]

Thanks :)

I've taken an interest in orbot and orwall, and while we're considering how to get logging so that we can help users better understand what connections a desired app needs to make, it occurred to me that it would be great to hand off iptables management to some other app, rather than reimplement. orWall comes with its own stringent expectation of privacy, and so it also includes boot scripts and (in the future) widgets for short-term bypass of select apps -- so it has its own opinions, but it seems to only be a slight superset of AFwall's goals.

Is that enough info to be helpful?

[patcon]

Oh hey, I really appreciate the thought and consideration on this! I don't suppose you're on IRC and we could have a quick chat today or tomorrow? I feel like we're still slightly on different understandings. I'm "patcon" on freenode and you can find me with /whois :)

cc: @cjeanneret

[cjeanneret]

Ohey!

orWall dev in here :).

On my part, using some third-party app in order to command iptables wouldn't be that hard, in fact: all the "magic" is in one class, wrapping the whole stuff. Meaning it wouldn't be that hard to give a try.

Would be indeed interesting seeing if AFWall could provide some Intent in order to "take orders"… On orWall part, I don't think this would change big things, as said. But, of course, in AFWall… it will be a bit different ;).

Here are the "plus" I can see for now:

• get only one application really managing iptables — orWall would just need to talk to AFWall
• thus get only one app asking for root
• may allow to do some more tricky things with iptables
• may also remove the "incompatible app" thing, as orWall would just talk to AFWall — no more problems (well, ok, in order to really avoid any problem, it will ask for time and huge dev, with many checks and so on)

If such intents are being added, this would also mean AFWall will become some kind of "dev-friendly interface to iptables". And this might be good (provided we can see which apps are subscribed to the intent, and get some way to block the ones we don't want to let access iptables).

BUT this changes a lot of things in AFWall design and purpose I guess… ?

I'm also on IRC, swisstengu is my name, and you may catch me on freenode (and some other networks).

Would be great if we could have a talk. I'm pretty sure the "dev-friendly interface to iptables" might get some interests and concerns.

Cheers,

C.

[patcon]

Wahoo! I suggest we join #fdroid channel if we get to talking. They have logging and would be nice to link the discussion here to make sure it's accessible to anyone else interested

[cjeanneret]

woops, mixed up my twitter and irc account, sorry: tengu is for irc, swisstengu for twitter -.-'

[ukanth]

Sorry for late response, Yes. There are plans to expose API (intents) for other application to leverage the iptables functionality. I would like get some use cases. I may not be able to join IRC, but I'll check this thread here.

[cjeanneret]

hello @ukanth ! Good news regarding the intents/API :+1:

Hints and use cases:

• add/remove iptables rules in filter and nat tables
• let AFWall manage the application UID so that we don't duplicate code (that's what I'm currently doing for orwall, it's ugly and I hate doing that :( )
• get some log interface in order to be able to debug iptables rules from other programs (meaning: call to nflog reader, for example)

Regarding the iptables rule management: AFWall should maybe check if the syntaxe is correct, though this part might be really hard seeing how iptables works… At least it should ensure we don't push the same rule twice.

[cernekee]

add/remove iptables rules in filter and nat tables

You might want to consider providing a higher-level interface, so that different apps do not create rules that conflict with each other. For the case of Tor/orWall/VPN/etc. it could be useful to let AFWall handle the details of routing traffic for each UID on the system: direct, Tor, VPN, or blocked.

[patcon]

Came across this, for anyone interested: https://github.com/ukanth/afwall/wiki/HOWTO-OrWall-together-with-AFWall

Thanks @CHEF-KOCH!