Date: Tue, 12 Jun 2001 14:46:56 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Mike Silbersack <silby@silby.com> Cc: gzjyliu@public.guangzhou.gd.cn, hackers@FreeBSD.org Subject: Re: [PATCH] Limited BPF to the specified program Message-ID: <Pine.NEB.3.96L.1010612144412.75080C-100000@fledge.watson.org> In-Reply-To: <20010611232418.V3383-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Jun 2001, Mike Silbersack wrote: > On Tue, 12 Jun 2001 gzjyliu@public.guangzhou.gd.cn wrote: > > > > Seems I can't contact the coordinator(eivind@FreeBSD.org) of this > > task. So I think maybe I should send the patch to this list. Here is > > the patch for limiting bpf access to the specified program. > > > > For example, if I wanna specify only /sbin/dhclient can use bpf, I > > can: > > The idea sounds neat, especially for computer labs and the like. > Unfortunately, I think this implementation is far too difficult to be > used effectively. Could you instead cause bpf to only return packets > dhclient would use? That would allow bpf to be used by any process, but > only be useful to dhclient. One of the things I actually played with implementing in the past was in effect an "ACL" of allowed BPF programs by-uid. When a BPF program was bound to an interface, the bpfilter code would hash by uid, then do a rather expensive walk down a list of "acceptable filters" and see if the program matched. This meant that you could, for example, allow specific users to monitor specific types of packets (such as a specific port). Since there isn't really a canonical form other than the de facto form libpcap generates bpf code in, there are some limits to this, but it worked fairly well. I didn't attempt to deal with the "which interfaces can they bind" issue, however. I can see if I can dig up the code, or it's fairly easy to replicate if not. For it to work right in jail, I had to strip an extra access control check in the bpf code, I think. I suspect a recent jail commit of mine (probably the ucred commit) removed the extra check, causing bpf to rely only on the device node file permissions rather than arbitrary suser stuff to limit access. 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-hackers" 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.1010612144412.75080C-100000>