Firewall block all but pass out single program

[kpedersen]

Hi all,

A system that works pretty well for Windows (i.e to block auto-updates or stop programs with DRM from working*) is to block everything (in and out) and only allow through a single program that I use (such as Firefox, CoreNetworking-DHCP, CoreNetworking-DNS).

I was wondering if I can use a similar system for FreeBSD (even though programs don't auto-update or have DRM). My knowledge of pf is extremely limited but something like

/etc/pf.conf

udp_services = "{ dhclient, dns }"
tcp_programs = "{ /usr/local/bin/firefox }"
block in all
block out all
pass proto udp to any port $udp_services keep state
pass out $tcp_programs keep state

Does anyone else do similar? Does anyone see security issues with this (other than Firefox potentially doing random things)?

Thanks

*So I can pinpoint them and find a suitable "fix".

 

[SirDice]

A firewall works on the network layers, how is it supposed to know which application created the network traffic?

 

[kpa]

There's limited support for such feature in the firewalls of FreeBSD. It's possible to detect the user and group of a socket used for sending and receiving but that's about it. Of course it's useless for forwarded traffic. For example in pf(4) you can say (this is directly from pf.conf(5)):

The following example allows only selected users to open outgoing connections:

                 block out proto { tcp, udp } all
                 pass  out proto { tcp, udp } all user { < 1000, dhartmei }

 

[throAU]

A firewall works on the network layers, how is it supposed to know which application created the network traffic?

Windows can do it. If FreeBSD can't do it then perhaps a decision has to be made as to whether or not it is a good idea.

Presumably there is some way of knowing the owner of a socket, and the full path of the executable that opened it? My shell can give me the full path of any processes I am running, so the info is there, it's just a matter of whether or not to harvest it. This could potentially be useful (?) if it could verify checksums as well - so you could keep a port blocked outbound unless a particular executable (path + checksum) wants to talk on that port. This would prevent the executable being killed and something else stealing its firewall exception rule to send traffic outbound.

 

[kpedersen]

So going from what @kpa suggested, it could be (partially) done by setting up a Firefox-firewall-allowed user and just using that for starting Firefox. I might do that, it doesn't seem too bad I guess.

I understand that the firewall works on network layers but I have noticed that most software that likes to do sneaky/pointless things uses HTTP (port 80) anyway so if I did let that through then that isn't going to be stopping this sort of behavior. Is there anything slightly higher than the firewall that you guys know of that can do this? I don't suppose Wireshark allows us (or can be patched) to cancel packets if we don't like them?

 

[kpa]

Such application level firewall really does not belong in the kernel because of the interdependencies between the kernel and the userspace should be kept at minimum. You see this already in pf(4) where the kernel code can not itself read files at all but depends on the userland utility pfctl(8) to compile the textual information from files into something that the kernel code can read trough /dev/pf. Such application level firewall would require certain virtualization of the network stack where applications would not talk directly to the interfaces but trough virtualized interfaces that have the application level firewall underneath controlling what is allowed and what is not.