Re: nftables.service hardening ideas

[Florian Westphal <fw@strlen.de>]

Christoph Anton Mitterer <calestyo@scientia.org> wrote:
> Hey.
> 
> On Tue, 2025-10-28 at 17:26 +0100, Florian Westphal wrote:
> > 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.
> 
> Uhm... well the point of any sandboxing is always (at least trying to)
> prevent any attacks.

Sure, but then we're talking about e.g. bug in dns resolver/parser
or something like that.

In general I don't believe Linux is capable of isolating against
abusing userspace, unfortunately.  Especially with CAP_NET_ADMIN
(which is very broad and provides access to many facilities in
 the kernel) or with unprivilged user namespaces enabled (the default,
sigh).

> Sure, nftables is probably not the most likely program to be abused (in
> particular as it usually won't process untrusted input), but still even
> nftables can't be 100% sure to never be abused in something like
> secretly included malware or so.

In that case I think all bets are of.

> As with the first patchset my idea was simply that *if* a .service file
> is shared it could as well be proper and use as many sandboxing options
> from systemd as possible, serving as and example for e.g. downstream
> versions of such .service.

Ok, if you want then feel free to start to send patches.
(and CC Jan).

I think that enabling CAP_NET_ADMIN restriction is fine,
otoh if you think that this should be done then I believe
its better to patch nft and not rely on systemd for this.