Date: Sun, 21 Apr 2002 09:45:07 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Doug Barton <DougB@FreeBSD.org> Cc: Craig Boston <craig@gjgth.gank.org>, current@FreeBSD.org Subject: Re: Adding a 'bpf' group for /dev/bpf* Message-ID: <Pine.NEB.3.96L.1020421093834.91313G-100000@fledge.watson.org> In-Reply-To: <20020420213227.R15997-100000@master.gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Apr 2002, Doug Barton wrote: > On Sat, 20 Apr 2002, Craig Boston wrote: > > > Since -current by default uses devfs, is there a standard way to make the > > ownership/permissions of device nodes "sticky" so that they persist across > > boots? > > rc.devfs Unfortunately, this works poorly for cloned devices. At various meetings, there has been discussion of a devfsd and/or devd; that's probably the vehicle for doing that kind of administrative change. Unfortunately, it doesn't exist yet, although I think Warner had done some prototyping. For now, the only place to make the change is in the kernel, and for a variety of reasons, that's not really desirable (maintaining duplicated passwd entries in statically compiled kernel code isn't wonderful, especially given that we're starting to collide our reserved uids with uids on older UNIX boxes and NIS networks). The BPF group idea is an interesting one from the perspective of assigning users to the group so that they can sniff without great privilege. However, it's worth observing that BPF actually implicitly gives you more rights than it appears if you assign "write" access to the device, including the ability to *produce* packets that source from other IP addresses and hardware addresses, to influence the localhost interface (which is frequently presumed to be highly trusted), etc. I'd be very cautious about introducing this feature into the base system without some pretty careful analysis first. Off hand, the concerns I'd have would include: - Provides a very high level of privilege relative to the LAN/PPP segments the system is on, in particular relating to the production of link layer network packets that normally the network stack doesn't permit (arp, IP, etc). - Allows bypassing of normal network stack protections that local applications rely on, including the historical "port 1024" limits, especially on the localhost interface. - For tunnels, abiity to bypass tunnel protection policies. There's probably more going on also. We should in particular sit down and see whether just providing read access (root:bpf, -rw--r---) is sufficient to protect against these problems. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020421093834.91313G-100000>