PF kern.securelevel 3 no longer allows listing of firewall rules?

Hi gang,

I suspect this to be a bug, but before I submit a report I figured I'd ask around here first:

Code:
root@vbsd:/home/peter # grep pf /boot/loader.conf /etc/rc.conf
/boot/loader.conf:pf_load="YES"
/boot/loader.conf:pflog_load="YES"
/etc/rc.conf:pf_enable="YES"
/etc/rc.conf:pflog_enable="YES"
root@vbsd:/home/peter # pfctl -sr
root@vbsd:/home/peter # sysctl kern.securelevel=3
kern.securelevel: -1 -> 3
root@vbsd:/home/peter # pfctl -sr
pfctl: Operation not permitted
root@vbsd:/home/peter #

(edit) => Forgot to include my system specs:

root@vbsd:/home/peter # uname -a
FreeBSD vbsd.intranet.lan 15.1-RELEASE-p3 FreeBSD 15.1-RELEASE-p3 releng/15.1-n283611-88e7371d9dc2 GENERIC amd64

Secure level 3 should block firewall rule changes, but surely you should be able to still view them? IMO it would otherwise seriously defeat the purpose of security if you can't even confirm that your firewall is actually active.
 
In the mean time I looked deeper into this; I can reproduce the issue on both my Hyper-V testing ground as well as my VPS server(s). I also noticed that the problem isn't limited to secure level 3 but starts 'lower':

Code:
root@vbsd:/etc # sysctl kern.securelevel=2
kern.securelevel: 1 -> 2
root@vbsd:/etc # pfctl -Fr -f ./pf.conf
rules cleared
pfctl: DIOCSETDEBUG: Operation not permitted
root@vbsd:/etc # pfctl -sr
root@vbsd:/etc #

However, at this time I can't yet confirm if this problem is limited to pf or also applies to other firewalls. Still, I know from personal experience that this didn't happen before. Later today I'll try to expand my test case.

(figured a new comment was cleaner than just editing my previous one).
 
Hi there,

Secure level 3 should block firewall rule changes, but surely you should be able to still view them? IMO it would otherwise seriously defeat the purpose of security if you can't even confirm that your firewall is actually active.
I can't comment on that, but there are changes to the securelevel of pf in main and stable/15, see below.

I also noticed that the problem isn't limited to secure level 3 but starts 'lower':
The issue seems to be addressed to in the "pf: fix securelevel off-by-one" commit on 2026-08-03 I'v looked up in the source git logs. Some "securelevel" values have been changed in sys/netpfil/pf/pf_nl.c.
Code:
cmd_securelevel is the securelevel at which the call should be denied.
pf (write) calls should be denied at level 3 or up (not at 2 or up as it
was), so increment these all by one.

PR:        296838
MFC after:    4 weeks
Sponsored by:    Rubicon Communications, LLC ("Netgate")
Differential Revision:    https://reviews.freebsd.org/D58377

It's been MFC'd to stable/15. Perhaps the changes will land in the next 15.1-RELEASE security/errata update, if not, then in the next minor RELEASE update, which would be 15.2.

If needed urgently, the patch can also be applied to the releng/15.1 branch now.
 
Back
Top