Commands to allow `/usr/libexec/bootpd` through MacOS firewall keep being executed while it doesn't seem to be blocked

What Happened?

I use a company-managed MacBook which has policies for setting up firewall rules, so I cannot run the suggested socketfilterfw commands.

Then, every time I run minikube start with --driver=qemu --network=socket_vmnet, it tries to run the commands because it can't find /usr/libexec/bootpd in the output of /usr/libexec/ApplicationFirewall/socketfilterfw --listapps.

The commands seem to be successful, but it's a false-positive, since MacOS returns exit code 0 when managing socketfilterfw is blocked.

❯ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/libexec/bootpd
Firewall settings cannot be modified from command line on managed Mac computers.
❯ echo $?
0

However, it does seem like /usr/libexec/bootpd is allowed to receive incoming connections. Here's why:

It is on an exceptions list in /usr/libexec/ApplicationFirewall/com.apple.alf.plist along with some other system services like mDNSResponder. I'm unsure if this is specific to my OS installation.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>allowsignedenabled</key>
  <integer>1</integer>
  <key>allowdownloadsignedenabled</key>
  <integer>1</integer>
  <key>applications</key>
  <array/>
  <key>exceptions</key>
  <array>
      ...
      <dict>
          <key>path</key>
          <string>/usr/libexec/bootpd</string>
          <key>state</key>
          <integer>3</integer>
      </dict>
     ...
  </array>
  ...
</dict>
</plist>

If I build minikube with the bootpd-related checks in cmd/minikube/cmd/start.go commented out, the commands are not executed and I don't see any errors related to IP assignment. I'm also able to SSH into the VM and minikube ip shows a local IP address.
The logs (atttached) shows it is able to get an IP for the VM from /var/db/dhcpd_leases.

That being said, I'd like to, first, understand if there are any other avenues for checking if bootpd is indeed working fine. It seems to me that we could delay the firewall rules checking to when/if we stumble upon an IP-related error. Happy to suggest a patch!

I'll also follow up on this after I have some time to install a clean version of MacOS in a VM to see if these exceptions in the com.apple.alf.plist file are there by default.

Attach the log file

I0920 21:18:32.337986   89934 main.go:141] libmachine: Attempt 8
I0920 21:18:32.338053   89934 main.go:141] libmachine: Searching for 62:e0:94:7:97:3e in /var/db/dhcpd_leases ...
I0920 21:18:32.338682   89934 main.go:141] libmachine: Found 9 entries in /var/db/dhcpd_leases!
I0920 21:18:32.338889   89934 main.go:141] libmachine: dhcp entry: {Name:minikube IPAddress:192.168.105.7 HWAddress:62:e0:94:7:97:3e ID:1,62:e0:94:7:97:3e Lease:0x66ef6256}
I0920 21:18:32.338894   89934 main.go:141] libmachine: Found match: 62:e0:94:7:97:3e
I0920 21:18:32.339005   89934 main.go:141] libmachine: IP: 192.168.105.7
I0920 21:18:32.340231   89934 main.go:141] libmachine: Waiting for VM to start (ssh -p 22 docker@192.168.105.7)...
I0920 21:18:33.378334   89934 machine.go:93] provisionDockerMachine start ...

Operating System

macOS (Default)

Driver

QEMU

### Tasks
- [ ] Spin up a VM with a clean installation of MacOS to check if `bootpd` is in `com.apple.alf.plist`.

kubernetes / minikube