Suppose one is running a single internet-facing daemon, as a service in a FreeBSD jail, and expects targeted hostile attacks targeting open WAN ports and services.
Like many services, the service and indeed its jail don't need interactive user login or ssh, as it can be completely configured and managed by editing its boot/rc files from the host login, and its logs can be monitored the same way.
So it's very tempting to look at attack surface, and remove/deny/disable everything that an attacker could use to escape the jail or pivot to other networked devices.
As a first step, trivial package dependencies for the desired service are easy to identify, allowing many files and packages to be removed, and also root and other builtin accounts can be set to shell=nologin (or at least no interactive login), standard jail sysctls can be used, packages kept updated, and other services potentially used to gain access can be avoided (no sshd/ftp/email).
But assuming an attacker can find an exploitable vulnerability in the daemon, what other configuration might be worth removing from the jail or restricting (capabilities, access rights, or essential system utilities), in order to harden the jail and hamstring an attacker who managed to exploit a vulnerability within the jailed service, or even one who discovered a way to gain root within the jail.
(Threat model note: Physical access, social engineering/phishing, and high speed brute credential forcing, aren't relevant to the question. I'm taking as a starting point, a remote determined attacker who can access a port or running service in the jail, and hopes to exploit a discovered vulnerability to escape the jail and attack its host)
