Does AFWall+ need to constantly run su/privileded-mode?

[hsanjuan]

Hello, I have started using AFWall+. So far so good, except CM13 displays a "#" sign on the notification bar which means something is running with root permissions.

I understand this is necessary when logging is enabled. But other than that, can't AFWall+ just use "su" when it needs to perform some occasional privileged operation (reading/writing the iptables), and not constantly all the time? I'm not very familiar with the app, but it'd seem a good practice to gain root privileges only when an operation requires them and not keep them constantly. Regards!

[ukanth]

This has been answered already. AFWall+ needs to reapply the iptables rules on connectivity change. Acquiring and applying rules takes longer time. That's the reason it root shell is required and it's not for logs.

[hsanjuan]

Thanks for getting back... I am sorry I have not found the previous question. I would be grateful if you can point me to the relevant discussion.

That said, I don't fully understand your answer. Why don't just re-acquire the root shell when there is need to reapply the rules? It should not be much slower (assuming the user has granted root permissions indefinitely to the app).

The main problem is that I understand this "#" icon a warning: "Watchout: Something is using a root shell permanently in the background". This, I understand, is not an expected behaviour in general (so they put an notification about it). If AFWall+ assumes that behaviour, there is no way to be warned if some other app maliciously does it. I understand that actively logging etc. might require this. But I'd prefer the root shell to be released when it's not used.

[hsanjuan]

Fair enough. I think the reason that "everyone is whining" is that the app keeps root privileges when it doesn't need them. When I realized this my first question was: what is this app doing that it needs to keep a root session all the time? So, you tell me, it is doing absolutely nothing, and that it just keeps it for convenience to save a few milliseconds on the next connectivity change. Well, fair enough, but you cannot have me believe that it surprises you that people asks what's going on with it nevertheless.

I never said that it was insecure. I just said it is usually good practice to drop privileges when you don't need them. Since AFWall+ does not drop them, that simply raises questions about how the app is functioning (and as a side-effect the # icon is an annoyance that could be avoided).

So yes, please, put it in the FAQ and explain why it needs an open root shell all the time and you will save threads like this. I did check the FAQ but I do apologize I didn't see that #458 has as similar discussion and I do THANK YOU for taking the time to answer. Best regards and thanks for this app.

[hsanjuan]

The '#' icon is a security feature as you said. IMHO there is nothing wrong with it. Apps are not expected to run root shell continuously in the background unless they are actively doing something (say logging).

Yes, the ROM could have a 'do not warn about this app' option. But AFWall+ could also release the shell when it's not in use (which, again, seems a logic thing to do after you have set up the necessary iptable rules). This is your implementation choice of course, and as said before, do what you like.

I'm of course not going to go to Cyanogenmod people and lobby them to tweak a perfectly fine feature just because you're lazy to drop an idle root shell. This has nothing to do with other apps or Android, it has to do with not using root when you don't need to. It this pisses you off, well that's fine, but you fail to see it's AFWall+ behaviour that raises the questions because it does not work as someone would expect.

I'm closing this as there is nothing left to discuss. And btw, don't take things so personal. I was never "whining", never intended to post "over and over again". I just opened a thread to ask a simple question and have tried to explain why this question arises. Take care.

[c3ph3us]

ok i have question on re applying rules - some concurrency scenario

installed both:

1. afwall+
2. orwall

both are reapplying rules on conn changes

question:

do u use any synchronization to maintain consistency of changes ?

why ? both in same time changing tables !

let me quote a passage on this matter:

Iptables and ?
Requiring auditing iptables sounds not all that complicated. However it would be good to realize how iptables works (and who/what works with it). To summarize: Iptables (better: the Netfilter framework) works by having the (/sbin/)iptables binary read the default configuration file (/etc/sysconfig/iptables on RHEL) and supply that data, the ruleset) to the kernel (as the kernel must never be allowed to read userland). The ruleset is loaded at system bootup by the initscript and can be unloaded or reloaded by those that can execute the initscript. A system can also contain one or more applications that provide a user with a remote, commandline, curses or graphical interface to alter the ruleset (the application itself interfacing with the system using the iptables binary), at runtime the ruleset can be altered by users who can execute the iptables iptables binary (or Sudo), and there may be applications that automate ruleset changes (Snort third party applications like Guardian, fail2ban or equivalent) in specific, designated chains for traffic blocking purposes.

Breaking down the requirements
Having realized the auditing subject breaks down in to three distinct areas: binary, on-disk and in-memory configuration, access, and if I get this correctly, your extended auditing requirements are for:

• the iptables binary (DAC, hash),
• the iptables configuration files (DAC, hash, changes),
• present iptables configuration (changes),
• issued iptables commands (user logging),
• log monitoring, (Sudo, any third party applications),
• iptables running state.

Monitoring static files
Any static filesystem item (a regular file residing on a regular fs) has DAC rights (ownership and access rights) and a checksum. In file integrity verification (and auditing) checking these basic attributes help ascertain a file has not been tampered with. (SELinux works on top of DAC rights to make certain only users with the right context can Do Stuff). Well-known OSS file integrity verification applications can be divided in three classes according to response time (looking at internal features): passive (Aide, Integrit, Osiris, tripwire, rpm), active (Samhain, Monit) and instantaneous (Auditd). Passive here means the application has no internal features that would allow it to run as a daemon (like Samhain and Monit can) and has to be run manually or as a cronjob. RPM can be used to verify file integrity but of course in terms of configurability its scope is limited to only those files that are installed by RPM. Like Samhain, monit can check file hashes at an interval. Auditd, the SELinux logging companion, works like iptables in that it uses an in-kernel ruleset to determine what it needs to log. Reading /var/log/audit/audit.log therefore provides alerting on a near-instantaneous level. For example enabling a rule "-w /etc/sysconfig/iptables -p w -k CFG_iptables" in /etc/audit/audit.rules (or use 'auditctl') will result in a logged line with the "CFG_iptables" tag at the moment /etc/sysconfig/iptables is written to. (Logging implies reading logs or parsing them: we'll get to that later on.)
Hint: One remark about risk vs performance: having any file integrity verification application check the system continuously for a large set of files will result in degraded performance due to I/O. It is therefore perfectly possible, in cases maybe even recommended, to determine your strategy. If you use three tiers you could have Auditd concern itself with contents of /etc (and anything mentioned in the CAPP, LSPP, NISPOM or STIG rulesets, see: /usr/share/doc/audit-/.rules), run Samhain on a half-hourly schedule targetting crucial binaries and risk areas like HTTP upload or inbound FTP directories and run Aide on a four hour scheme to cover anything else that requires covering.

• Warning: since you indicated having multiple root account users this implies that any root account user can change configuration. It is strongly advisable to enable * independent, remote file integrity verification with Samhain + Beltane or webjob + a file integrity verification application of your choice.
• Caveat: auditing changes in hashes or DAC rights is complementary: it will for instance not show which user changed something or what content changed.

Monitoring dynamic content
Taking iptables as example we know that 'cat /proc/net/ip_tables_names|xargs -iX iptables -n -L -t 'X' ' will output all rules. We know that creating a checksum can be done reading stdin. Therefore running 'cat /proc/net/ip_tables_names|xargs -iX iptables -n -L -t 'X' |sha1sum' will provide the hash for the combined result of outputting all loaded iptables rules. Storing the hash allows for easy comparison later on. Following the same principle you can easily expand checking to a chain or even rule level. Automating this is not hard. In absence of something better I do use a script myself for the purpose of validating dynamic contents of different Netfilter tables. (If you want help with creating such a script feel free to have a go at it, create a separate thread in the LQ /Programming forum and add your code.) And since the hash won't match if the iptables ruleset is not loaded or not loaded properly this also covers the "iptables running state" part).

• Hint: note that if you already deploy remote monitoring a script similar to the 'cat ..|sha1sum' oneliner could be used to drive a /etc/xinetd.d/ script to provide the hash over say HTTP for comparison.
• Warning: for local binaries to produce results or checks to trust, it is required to verify the integrity of the system.
• Caveat: there may be firewall ruleset management applications that allow you to verify ruleset integrity. I just don't know of any. Doing research never hurts. On Sourceforge you will find the ITVal project that promises you help with validating changes to your firewall policy. It just didn't work for me. Feel free to try.

Monitoring content changes
Like GNU/Linux does not come with extended auditing enabled, it has no default means to record, play back or display differences in configuration files. File integrity verification applications can tell you in the most simplest of ways if something changed, not what. (Any tool based on) Rsync or large scale system versioning and configuration management suites (Puppet, Cfengine, et cetera) may help you solve this problem. (All implying trusted remote storage BTW).

• Warning: since you indicated having multiple root account users this implies that any root account user can change configuration. It is strongly advisable to avoid kludges or solutions that solely depend on local means.

Logging, log monitoring, remote logging
Note that when talking about a "root account user" we talk about qualified and authorized systems administrators. This means that root account usage rights given to any user out of laziness (e.g. instead of figuring out more secure means) should be take away immediately and replaced with the appropriate Sudo configuration. Note that this even goes for users who require access to multiple commands that need to be run as root. Sudo can easily be configured to accomodate those types of users. As this system has multiple root account users it is crucial to provide each with a separate unprivileged user account to start out from. No user should be allowed to log in as root on the console (and definately not from remote!). (And also mind your password complexity and aging!)

• Warning: ignoring the above will severely impact security and limit auditing integrity.

While Sudo (when appropriately configured) will log issued commands it will not do so for users that have been allowed root account access. To provide separated per user, independent, timestamped logging of commandline (and output!) you will configure those unprivileged user accounts to use 'Rootsh' to sudo to root by allowing them to run something like 'sudo rootsh -u root -i'. Depending on configuration the logfiles may go to /var/log/rootsh or syslog. In addition to monitoring above this will provide you with enough of an auditing trail to help you determine which user changed what files contents at what time.

• Warning: with multiple root account users you are strongly advised to enable logging to a trusted, remote syslog server for about everything.

Logging means reading logs. Without automating it this soon becomes more than a 24/7 job. For instantaneous response to priority 1 alerts you will need a log watcher like Swatch or SEC (or search Freshmeat, Sourceforge, Nongnu, Berlios) that can alert (and respond) to alerts by filtering for certain regexes. For logging at intervals you could use for instance Logwatch.

• Hint: what you want is close to PCI-DSS type of logging. Be sure to search this forum for threads about it as you will find more information there.

Wrap-up
I hope that from reading the above you understand that by thoroughly assessing the situation you find that "auditing iptables" involves more layers of security than just checking hashes, and that while GNU/Linux does not come with the required silver spooning out of the box it is perfectly possible to convert your requirements into a practically usable audit trail. Your Achilles heel is having multiple root account users which may not be avoidable. Besides I may know some but I don't know everything. So making sure this all works for you will involve more than just blindly implementing what's been offered: thinking about circumvention or evasion, research possible solutions, take the right measures (how would you be alerted to and what would you with a log DoS?) and discussing things.

[c3ph3us]

do u know meaning a word "quote" ? <- retoric question :)

for many people when u give a source the are to lazy to read it :)
second internet sources are vanishing in the same rate as they are appearing!
so creating archive is a good thing .. i think )
last my point was to ensure you are aware of all "requirements" for security issues

see also:
https://unix.stackexchange.com/questions/206891/audit-on-changes-to-the-running-iptables-configuration#answer-206894

ps: audit is not off topic as on my screen notoriously i see:
afwall+ blablabla superuser
orwall - blablabla superuser

[hsanjuan]

@CHEF-KOCH thanks for clarifying!

[cernekee]

Why don't just re-acquire the root shell when there is need to reapply the rules? It should not be much slower

I added this feature because opening a new root shell is a slow operation and we had performance issues on some devices. It is also recommended by Chainfire's guide:

Many su calls throughout the app's lifecycle
Some apps need to make a lot of su calls throughout the app's lifecycle but can't batch these commands together. In such a case you should consider starting an interactive su shell and keeping it alive alongside your app, so you can pipe commands to it as needed. This might have positive effects on the performance and responsiveness of your application.

Regarding:

it is usually good practice to drop privileges when you don't need them

Only the iptables commands run as root, even when the shell is open. The rest of the app does not. This isn't the equivalent of calling setuid(0) and then performing a bunch of sundry unprivileged tasks. Unprivileged tasks still run unprivileged.

There's no real benefit in closing the root shell, because the app already has permission to re-open it at any time.

The '#' icon is a security feature as you said.

A truly malicious app that manages to get root access can hide the icon.

From looking at this code it seems that it only gets displayed when an app acquires root through the "front door." If a malware app gains root by exploiting a kernel vulnerability and then modifies the rootfs to make itself persistent, the icon will not show up. This could give users a false sense of security.

[cernekee]

Two other random tidbits I remembered after posting:

• Some people were annoyed by the Superuser toasts happening whenever AFWall wanted to reopen a root shell in the background. Connectivity changes sometimes happen unexpectedly, and it can be a little unsettling to see a toast notification pop up out of nowhere when you think the phone is idle.
• If the su daemon doesn't cache the user approval, requesting a root shell probably involves sending an intent to the Superuser app, which probably isn't running continuously in the background. If the app has to be started up, that can result in quite a bit of latency, and it could also increase memory pressure on low-end devices.

[L-a-n-g-o-l-i-e-r-s]

Hi there, semi-related, I have a wifi only tablet, I very rarely change to another wifi network when traveling, is it okay to disable active rules? Thanks.