Re: nftables.service hardening ideas

[Florian Westphal <fw@strlen.de>]

Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> This would be ideas about further hardening nftables.service, primarily
> using the options from systemd.exec(5).

Whats the point?  nft will exit anyway.

> which not only mounts some but the entire fs hierarchy read-only for
> the service's commands.
> I guess nft -f should never write anywhere, or does it? At least it
> seems to work.

nft -f should not write anything.

> 4. I guess nft needs no capabilities/privileges other than
> CAP_NET_ADMIN:
> > CapabilityBoundingSet=CAP_NET_ADMIN
> > AmbientCapabilities=""
> > NoNewPrivileges=yes
> 
> CapabilityBoundingSet=CAP_NET_ADMIN would supersede the =~CAP_SYS_ADMIN
> from (2) above.

CAP_NET_ADMIN is mandatory and should work as only capability.

> AmbientCapabilities="" disables all ambient capabilities, I'd blindly
> guess that nftables doesn't execve(),... but it shouldn't harm either.

It doesn't execve.

> 5. There should be no reason why nft -f needs to access stuff in /tmp
> or /var/tmp of anything else, so:
> > PrivateTmp=yes

Makes no sense to me.  nft -f won't write anything.

> 7. AFAICS, nft -f may cause modules to be loaded, but that's done
> indirectly (i.e. I guess by the kernel itself?)

nft relies on kernel module autoloading.

> So leats get a bit more exotic ;-)

Exotic? More like estoteric, this is bad.  Service file should be small and not rely
on obscure and maybe not well-tested systemd code paths.