filesystem access to add/remove/view ip addresses

filesystem access to add/remove/view ip addresses

[Telbat Diordna]

In iptables there exists the recent module (-m recent). This gives you
the possibility to add and remove ip addresses in rulesets (usually
blocklists).  The advantage of this method is, that you can allow
access via FACLs to ordinary users for selected configuration items.
E.g.:
echo +/- <ip> > /proc/net/xt_recent/<iptname>

Looks like, that in nftables there is no recent module. How can I use
nftables in a similar way?

Thanks for any information/link etc.

t.d.

Re: filesystem access to add/remove/view ip addresses

[Kerin Millar]

On Fri, 18 Oct 2024, at 8:30 PM, Telbat Diordna wrote:
> In iptables there exists the recent module (-m recent). This gives you
> the possibility to add and remove ip addresses in rulesets (usually
> blocklists).  The advantage of this method is, that you can allow
> access via FACLs to ordinary users for selected configuration items.
> E.g.:
> echo +/- <ip> > /proc/net/xt_recent/<iptname>
>
> Looks like, that in nftables there is no recent module. How can I use
> nftables in a similar way?
>
> Thanks for any information/link etc.

That's an interesting use case (that of defining FACLs).

To manipulate an nftables ruleset requires the CAP_NET_ADMIN capability. The only thing that I can think of is to write a program that would compose and dispatch the necessary set-manipulating commands through nft(8) or netlink(7), while exposing a simple command-line interface to its users. The binary could be granted the CAP_NET_ADMIN capability with the setcap(8) utility and either:

a) be limited to the relevant users and/or groups with chmod and chown
b) perform its own user and/or group membership checks upon execution

Unfortunately, this technique cannot be applied for executable scripts (BINFMT_SCRIPT), so the binary would need to be an ELF.

-- 
Kerin Millar

Re: filesystem access to add/remove/view ip addresses

[Kerin Millar]

On Sat, 19 Oct 2024, at 5:35 PM, Telbat Diordna wrote:
> CAP_NET_ADMIN opens the door ways to wide, while the older iptables
> method allowed access-limitations/permissions per directory (=ruleset)

If you cannot bring yourself to trust a homebrew BINFMT_ELF executable with the CAP_NET_ADMIN capability, another option would be to write a simple shell script to wrap nft(8) then compose a suitable policy for use with sudo(8). The paradox would be that sudo opens the door wider initially, on account of having the setuid bit be enabled.

> Can I read your answer in that way, that I still have to use iptables
> and can't migrate to nftables, when I wish to use this feature?

Yes, for the following reasons.

- no procfs interface exists to modify a ruleset or its objects
- nftables cannot integrate with xtables extensions unless using iptables-nft
- the procfs interface you are using is implemented by an xtables extension (xt_recent)

--
Kerin Millar

Re: filesystem access to add/remove/view ip addresses

[Pablo Neira Ayuso]

On Sat, Oct 19, 2024 at 08:35:36PM +0100, Kerin Millar wrote:
> On Sat, 19 Oct 2024, at 5:35 PM, Telbat Diordna wrote:
> > CAP_NET_ADMIN opens the door ways to wide, while the older iptables
> > method allowed access-limitations/permissions per directory (=ruleset)
> 
> If you cannot bring yourself to trust a homebrew BINFMT_ELF
> executable with the CAP_NET_ADMIN capability, another option would
> be to write a simple shell script to wrap nft(8) then compose a
> suitable policy for use with sudo(8). The paradox would be that sudo
> opens the door wider initially, on account of having the setuid bit
> be enabled.
> 
> > Can I read your answer in that way, that I still have to use iptables
> > and can't migrate to nftables, when I wish to use this feature?
> 
> Yes, for the following reasons.
> 
> - no procfs interface exists to modify a ruleset or its objects
> - nftables cannot integrate with xtables extensions unless using iptables-nft
> - the procfs interface you are using is implemented by an xtables extension (xt_recent)

For the record: We have absolutely **no** plans to provide a procfs
interface to populate sets.