On Mon, 11 Jun 2001, Mike Silbersack wrote:
> On Tue, 12 Jun 2001 [EMAIL PROTECTED] wrote:
> >
> > Seems I can't contact the coordinator([EMAIL PROTECTED]) 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
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
