devfs: add bpf examples

[tuexen]

Summary

Add an example for allowing members of the network group to access bpf devices. In particular, this allows members of the network group to monitor traffic without running with root privileges.

[markj]

In particular, this allows members of the network group to monitor traffic without running with root privileges.

It also lets those members inject packets... maybe the suggested permissions should be 0640 at least?

[glebius]

Sorry for slightly switching context. This actually links to the recent "regression" that I planted. With a new API to get exact list of possible bpf taps, instead of guessing via getifaddrs(3) + list USB buses, the building of the list requires privileges. Previously you could run tcpdump -D without privileges on FreeBSD, now it can't. The wireshark/tcpdump guys think that it is a regression and should be fixed.

There are two ways to solve:

1. Change permissions on /dev/bpf and do privileges checking inside the device code. Allow BIOCGETIFLIST for unprivileged user.
2. In libpcap fallback to getifaddrs(3)+/dev/usb guessing if opening /dev/bpf failed.

Your opinions?

[glebius]

Please take into account Mark's suggestion.

[tuexen]

Use 0640 as markj@ suggested.

[tuexen]

In D56742#1299590, @markj wrote:

In particular, this allows members of the network group to monitor traffic without running with root privileges.

It also lets those members inject packets... maybe the suggested permissions should be 0640 at least?

Done. I was using the setting 0660 for years since it was suggested in pkg-message.

[tuexen]

In D56742#1299817, @glebius wrote:

Sorry for slightly switching context. This actually links to the recent "regression" that I planted. With a new API to get exact list of possible bpf taps, instead of guessing via getifaddrs(3) + list USB buses, the building of the list requires privileges. Previously you could run tcpdump -D without privileges on FreeBSD, now it can't. The wireshark/tcpdump guys think that it is a regression and should be fixed.

I can understand that.

There are two ways to solve:

1. Change permissions on /dev/bpf and do privileges checking inside the device code. Allow BIOCGETIFLIST for unprivileged user.
2. In libpcap fallback to getifaddrs(3)+/dev/usb guessing if opening /dev/bpf failed.

Your opinions?

I would tend to 2. I guess most people run at least wireshark with 0660 on bpf devices, since this is what it recommended when the port is installed, they would get the new code with higher quality output. The rest gets what it was getting earlier.

[markj]

In D56742#1299817, @glebius wrote:

Sorry for slightly switching context. This actually links to the recent "regression" that I planted. With a new API to get exact list of possible bpf taps, instead of guessing via getifaddrs(3) + list USB buses, the building of the list requires privileges. Previously you could run tcpdump -D without privileges on FreeBSD, now it can't. The wireshark/tcpdump guys think that it is a regression and should be fixed.

There are two ways to solve:

1. Change permissions on /dev/bpf and do privileges checking inside the device code. Allow BIOCGETIFLIST for unprivileged user.

We shouldn't do privilege checking after the /dev/bpf file descriptor has been obtained.

2. In libpcap fallback to getifaddrs(3)+/dev/usb guessing if opening /dev/bpf failed.

Your opinions?

It must be 2) IMO. Isn't that also required to support running new libpcap on FreeBSD? There are supported releases which do not have BIOCGETIFLIST.

[markj]

sbin/devfs/devfs.conf

46

It can just be bpf, no? The bpf code only creates /dev/bpf and /dev/bpf0, and they are aliases. Globbing would match any hypothetical device files which start with bpf*.

[tuexen]

Use bpf instead of bpf* as suggested by markj@.

[tuexen]

sbin/devfs/devfs.conf

46

I tested using bpf instead of bpf* and it works as expected. Never tried that. Thanks for the hint.

[markj]

sbin/devfs/devfs.conf

44

The comment should probably explain that this allows members of the group to snoop all traffic in the system.

[tuexen]

Be more explicit in the comment as suggested my markj@ and rscheff@.

[tuexen]

sbin/devfs/devfs.conf

44

OK. The comment was similar to the other ones for consistency. But rscheff@ also suggested to be more explicit. So do this.