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

- 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
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to