Is it at all possible to execute iptables --list …. command without being root?

Running it as non-root prints this:

$ iptables --list
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

If you must be root to list iptables, what is the reasoning behind that ? Is there a security concern with viewing the rules ? Is there a resource or service used by iptables --list that requires root access ?

Obviously, modifying iptables firewall rules requires privileged user. I am asking about viewing them.

Instead of being root, is there a capability that could permit listing the rules ? Does iptables use netlink to interface with the kernel ? Because netlink documentation mentions that

Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability may send or listen to a netlink multicast group.

Maybe that does not apply to iptables.

I am not sure whether this is the right way of doing it but adding a capability to iptables does not let me list the rules either:

bash-4.1$ echo $UID
bash-4.1$ getcap /sbin/iptables-multi-1.4.7
/sbin/iptables-multi-1.4.7 = cap_net_admin+ep
bash-4.1$ /sbin/iptables-multi-1.4.7 main --list
FATAL: Could not load /lib/modules/3.10.0-514.21.1.el7.x86_64/modules.dep: No such file or directory
iptables v1.4.7: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded. 

Here are some relevant questions q1 and q2. Both provide workarounds in my opinion and do not discuss the fundamental reason behind it.

  • Do those linked questions really include a workaround though? I see suggestions to just use root and/or to use sudo, but both of those would allow the users to also modify rules no?
    – jesse_b
    Aug 10 '17 at 1:15
  • As a workaround they suggest to wrap sudo iptables in a script or call iptables in a cron job by root. I thought of these as workarounds to fall back to the privileged user in a different way.
    – Hakan Baba
    Aug 10 '17 at 1:19
  • 1
    Yea, but your question has me thinking there is a good use case for more granular iptables permissions. The first thing I thought when I read this was low tier support personnel could need the ability to view firewall rules as part of initial troubleshooting on an incident but have no access to modify them. If you gave them sudo permissions you would be giving them way more than just view iptables. Even as one person suggested giving them permission to sudo a script could be problematic but that sounds like the closest thing so far.
    – jesse_b
    Aug 10 '17 at 1:23

It appears iptables needs both CAP_NET_RAW and CAP_NET_ADMIN to be able to read the tables. I tried

$ cp /usr/sbin/iptables ~/iptables  # note, it may be a symbolic link
$ sudo setcap CAP_NET_RAW,CAP_NET_ADMIN+ep  ~/iptables
$ ~/iptables  -nvL

and it was ok.

  • The true answer, for a huge class of problems Jan 6 '19 at 15:37

Indeed, iptables uses the netlink interface to communicate with the kernel. It opens a netlink socket to xtables, then issues commands via this socket. Access control is performed when the socket is opened, not for individual commands, so the same permissions are required for listing and modifying rules. The only way to allow a user to list rules but not modify them is to give them a carefully-written setuid (or setcap) executable.

It would be nice if there was an interface to netfilter in /proc, but as far as I know the task of implementing it has never been completed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.