From owner-freebsd-current Sun Apr 21 6:45:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3A25A37B400; Sun, 21 Apr 2002 06:45:18 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3LDj8w01552; Sun, 21 Apr 2002 09:45:08 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 21 Apr 2002 09:45:07 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Doug Barton Cc: Craig Boston , current@FreeBSD.org Subject: Re: Adding a 'bpf' group for /dev/bpf* In-Reply-To: <20020420213227.R15997-100000@master.gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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