FreeBSD Security Hardening Guide: Securelevels, Jails, Capsicum and MAC Explained

FreeBSD runs underneath a large share of firewalls, storage appliances and network services, yet most hardening guidance and tooling is written for Linux and does not translate. FreeBSD has its own security primitives: kernel securelevels, jails, the Capsicum capability framework, the TrustedBSD MAC framework and BSM auditing. Used together they give a strong baseline, but none of them is switched on by a default install. This guide covers how identity and privilege work on FreeBSD, how to configure each control, what to log, and the misconfigurations that undo them. It is for administrators and security engineers who run FreeBSD servers or assess appliances built on it.

Key takeaways

• Raise the securelevel on production hosts: at level 1 or higher the kernel refuses to load modules or clear immutable flags, and no process can lower the level again without a reboot.
• Jails are the isolation unit, but thin and service jails share far more with the host than thick jails, so choose the type by the trust boundary you need.
• Root is still root: control it through the wheel group, sudo or doas rules, key-only SSH and named accounts, and treat every keytab and automation key as a privileged credential.
• Turn on BSM auditing (auditd) and ship trails off the host; default syslog does not record exec, file and authorisation events at the depth an investigation needs.
• Patch two layers separately: freebsd-update for the base system and pkg audit plus pkg upgrade for third-party packages, including every jail.

How identity and access work in FreeBSD

FreeBSD uses the classic Unix model: users and groups in /etc/passwd and /etc/group, with password hashes in /etc/master.passwd (built into the pwd.db and spwd.db databases). UID 0 bypasses discretionary access checks, so the hardening job is mostly about who can become UID 0, how, and what the kernel still refuses even to root.

• Login classes: /etc/login.conf sets per-class password hashing, expiry and resource limits. The Handbook gives SHA-512 as the default (:passwd_format=sha512:), expiry through :passwordtime=90d:, and process limits such as :maxproc=50:. Every change needs cap_mkdb /etc/login.conf to take effect, and existing hashes only change when the user next sets a password.
• PAM: FreeBSD uses OpenPAM with policies in /etc/pam.d/. Password complexity comes from pam_passwdqc.so in /etc/pam.d/passwd, which is commented out by default. See the Linux PAM Guide for PAM stacking concepts that carry over.
• Account locking: pw lock <user> locks an account, and chsh -s /usr/sbin/nologin removes interactive login for service users.
• Directory integration: the base system ships Heimdal Kerberos libraries, and OpenSSH supports GSSAPIAuthentication yes. Central identity (LDAP or Active Directory) is added through packages rather than the base system, so check who maintains that integration and how it is patched.
• Kernel-enforced limits on root: securelevel, file flags such as schg (system immutable), MAC policies and Capsicum all constrain what a compromised root process can do. These are what make FreeBSD hardening different from simply locking down accounts.

Securelevel reference

Enable with sysrc kern_securelevel_enable="YES" and sysrc kern_securelevel=2; check with sysctl -n kern.securelevel. Any superuser process can raise the level, but no process can lower it.

Securelevel is only as strong as the boot path. If an attacker with root can edit /etc/rc.conf and reboot, the level comes back lower. Set schg on /boot/loader.conf, /etc/rc.conf, the kernel and key binaries, and make sure console and boot loader access are physically or remotely protected.

Admin roles and privileged access

FreeBSD has no built-in role model beyond root and groups, so privileged access design is a matter of convention and tooling. The principles in the Unix and Linux Privileged Access Guide apply; the FreeBSD specifics are below.

• Named accounts first: every administrator logs in as themselves and escalates. Keep the root password in a vault for break-glass use only, and alert when it is used.
• SSH as the front door: set PasswordAuthentication no, PubkeyAuthentication yes, restrict with AllowUsers or AllowGroups, validate with sshd -t and apply with service sshd reload. Keep PermitRootLogin no. See the OpenSSH Server Hardening Guide.
• sudo hygiene: scope rules to commands, avoid editors, pagers and interpreters in rules, and log sudo output. The sudo and sudoers Security Guide covers rule review in depth.
• Visibility hardening: set security.bsd.see_other_uids=0, security.bsd.see_other_gids=0 and security.bsd.see_jail_proc=0 so ordinary users cannot enumerate other users' or jails' processes, and security.bsd.unprivileged_proc_debug=0 to stop non-root users attaching debuggers. The installer offers a hardening step that sets options of this kind; confirm the resulting values with sysctl rather than assuming them.

Jails, Capsicum and MAC: containing what root can reach

These three mechanisms solve different problems. Jails partition the system, Capsicum sandboxes individual programs, and MAC adds policy the owner of a file cannot override.

Jail types and their isolation

• Keep allow parameters off: each allow.* setting (allow.raw_sockets, allow.mount, allow.mount.devfs, allow.mount.procfs, allow.mount.tmpfs and so on) gives jail root a capability it does not have by default. Grant them only per jail, with a written reason.
• Restrict devices: pair mount.devfs with a restrictive devfs_ruleset so a jail sees only the device nodes it needs.
• Clean execution: use exec.clean so host environment variables do not leak into jail start-up commands.
• Limit resources: enable kern.racct.enable=1 in /boot/loader.conf, set rctl_enable="YES", and cap memory and processes per jail (for example jail:classic:memoryuse:deny=2G) in /etc/rctl.conf so one jail cannot starve the host.
• Patch every jail: run freebsd-update -j <name> fetch install and pkg -j <name> upgrade for thick jails, or update the shared template for NullFS thin jails. A jail's FreeBSD version cannot be newer than the host's.

Capsicum

Capsicum turns file descriptors into capabilities. A process calls cap_enter(2) to enter capability mode, after which it loses access to global namespaces such as the filesystem and PID space and can only use descriptors it already holds. cap_rights_limit(2) narrows what each descriptor allows (for example read only), process descriptors (pdfork(2), pdkill(2)) manage children without the PID namespace, and libcasper(3) provides helper services such as DNS lookups to sandboxed code. Capability mode is inherited and cannot be left. Capsicum first appeared in FreeBSD 9.0. It is a developer control: administrators cannot apply it to an arbitrary binary, but they can prefer software built with it and ask appliance vendors whether their parsers and network daemons run sandboxed.

MAC policy modules

For most servers the label-free modules (seeotheruids, bsdextended, portacl) give real value at low cost. The labelled policies (MLS, Biba, LOMAC) need a designed label scheme and testing, and a mistake can leave a system unbootable, so trial them on a non-production host first. The Handbook describes these as loadable modules or kernel options such as options MAC_BSDEXTENDED.

Integrations, API tokens and service accounts

FreeBSD hosts rarely stand alone. Configuration management, backup agents, monitoring and directory services all hold credentials on the box, and those non-human identities are often more privileged than any human account.

• Kerberos keytabs: a host keytab (default /etc/krb5.keytab) lets anything that can read it authenticate as the host. Keep it mode 0600 root, inventory every keytab, and rotate when a host is rebuilt. See the Linux Service Accounts and Keytab Management Guide.
• Automation SSH keys: configuration management and backup tools often log in as root with a key in authorized_keys. Restrict those keys with from= and forced commands, prefer a dedicated user with scoped sudo, and include them in key rotation. Unexpected additions to authorized_keys are a known persistence method (MITRE ATT&CK T1098.004).
• Service users: run each daemon as its own unprivileged user with /usr/sbin/nologin, and use mac_portacl rather than root to bind low ports.
• TLS private keys: keys generated with openssl req belong in a root-only directory, not in a world-readable web root. FreeBSD 14 and later can load the OpenSSL 3 FIPS provider (openssl fipsinstall) where a FIPS module is required.
• Appliance management APIs: firewall and storage products built on FreeBSD expose web and REST APIs with their own keys. Those keys are outside the operating system's account model, so govern them as you would any other API credential. See the Non-Human Identity (NHI) Guide.

Logging and detection

FreeBSD includes OpenBSM security event auditing. It is in the GENERIC kernel (custom kernels need options AUDIT) and is enabled with auditd_enable="YES" in /etc/rc.conf. Configuration lives in /etc/security/audit_control and /etc/security/audit_user, and trails go to /var/audit in binary BSM format, read with praudit and filtered with auditreduce.

• Rotate safely: use audit -n or the filesz setting, not newsyslog, and keep minfree sensible so trails do not fill the disk.
• Ship off the host: an attacker with root can delete local trails. Forward from /dev/auditpipe or syslog to a central collector.
• Detections worth writing: kernel module load attempts (T1547.006), changes to authorized_keys (T1098.004), sudo use outside change windows (T1548.003), root logins over SSH (T1021.004), changes to kern.securelevel settings in rc.conf, and new jails or changed allow.* parameters.

Hardening baseline

There is no single official FreeBSD benchmark that every organisation uses, so most teams write their own baseline from the Handbook and security(7). A practical order of work:

1. Inventory and patch: list every FreeBSD host, appliance and jail with its release and support status. Run freebsd-update fetch install and pkg audit -F, and subscribe to FreeBSD security advisories (named FreeBSD-SA-YY:NN.module).
2. Remove what you do not need: disable inetd and unused rc services, and if inetd must run, restrict it with /etc/hosts.allow (the default allows all).
3. Accounts and SSH: key-only SSH, no root login, wheel restricted, sudo or doas rules reviewed, service users on nologin.
4. Kernel and visibility sysctls: set the security.bsd.* visibility and debug controls, confirm ASLR (kern.elf64.aslr.enable and kern.elf64.aslr.pie_enable) and non-executable stack settings, and leave kern.elf64.allow_wx disabled unless an application needs it.
5. Auditing: enable auditd with lo,aa,ad plus exec for root, and forward logs.
6. Isolation: move internet-facing services into jails with no extra allow.* rights, a restrictive devfs ruleset and rctl limits. Load mac_portacl and mac_seeotheruids where they fit.
7. Lock it down last: set schg on boot and configuration files, then raise the securelevel. Test in a pilot first: once level 1 or higher is set, routine work such as loading a module needs a reboot to a lower level, so build that into change procedures. Rollback is a reboot with kern_securelevel_enable disabled from single-user mode.

Record the baseline in configuration management, and check drift with mtree baselines and periodic security reports. Small estates can manage this by hand with a written checklist; larger estates should template jails and rc.conf through configuration management so every host starts from the same state.

Common misconfigurations

• Securelevel set but not protected: raising the level without schg on rc.conf and loader.conf means a reboot quietly undoes it.
• Thin or service jails treated as tenant boundaries: a service jail offers no filesystem isolation, and thin jails share a template. Use thick jails, or separate hosts, for untrusted tenants.
• Jails that are never patched: the host is current but jails run old packages because nobody runs pkg -j or freebsd-update -j.
• Generous allow parameters: allow.raw_sockets and allow.mount added to get one tool working and left on every jail.
• Appliance management planes on the internet: many FreeBSD-based firewalls and storage systems expose web consoles and SSH. Keep management interfaces on a dedicated network. See the Edge Device Security Guide.
• Audit on, nobody reading: trails accumulate in /var/audit without forwarding, and fill the disk or get deleted after compromise.

Framework mapping

Practitioner checklist

• Inventory every FreeBSD host, appliance and jail with release, support status and owner.
• Apply base updates with freebsd-update and package updates with pkg audit and pkg upgrade, inside every jail too.
• Enforce key-only SSH with root login disabled, and restrict escalation to wheel plus reviewed sudo or doas rules.
• Set the security.bsd visibility and debugging sysctls and confirm ASLR and W^X settings.
• Enable auditd with login, authorisation, administrative and root exec classes, and forward trails off the host.
• Run internet-facing services in thick or VNET jails with no unneeded allow parameters, a devfs ruleset and rctl limits.
• Load mac_portacl so no daemon runs as root just to bind a low port.
• Inventory keytabs, automation SSH keys and appliance API keys, and rotate them on a schedule.
• Set schg on boot and configuration files, raise the securelevel, and document the reboot procedure for changes.

Standards and references

• FreeBSD Handbook: Security
• FreeBSD Handbook: Jails and Containers
• FreeBSD Handbook: Mandatory Access Control
• FreeBSD Handbook: Security Event Auditing
• FreeBSD Manual Pages: security(7)
• FreeBSD Manual Pages: capsicum(4)
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: SSH Authorized Keys

Related NHI Mgmt Group resources: Linux Server Hardening Guide · OpenSSH Server Hardening Guide · Unix and Linux Privileged Access Guide · Edge Device Security Guide