Re: Adding a 'bpf' group for /dev/bpf*
On Mon, Apr 22, 2002 at 11:16:58AM -0700, Doug White wrote: On Sat, 20 Apr 2002, Lyndon Nerenberg wrote: For the benefit of packet sniffers and other things that only want read-only access to /dev/bpf*, what do people think of adding a 'bpf' group for those programs? This allows bpf devices to be read by programs running with an effective gid of 'bpf' instead of the current requirement for an effective user of root. I've been running this way on many of our servers for several months now, and things like snort, tcpdump, etc., are quite happy with it (under stable). There's the other small problem that you have to be root to set promiscuous mode. Nope. Just read access to bpf(4). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
For the benefit of packet sniffers and other things that only want read-only access to /dev/bpf*, what do people think of adding a 'bpf' group for those programs? This allows bpf devices to be read by programs running with an effective gid of 'bpf' instead of the current requirement for an effective user of root. I've been running this way on many of our servers for several months now, and things like snort, tcpdump, etc., are quite happy with it (under stable). There's the other small problem that you have to be root to set promiscuous mode. Not on 4.x. Haven't tried -current. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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? No. Or should we just put the appropriate commands in rc.local ? The problem has been moved to putting them in devfs. Besides bpf, this would be useful, for example, for people who want to change permissions on cd-rom devices to 644 so that non-root users can make iso images (or give a special group cd burner rights). I think you mean mode 660. acd devices already have the insecure permissions 644 in devfs. These are even more insecure than they should be, since read permission is enough to do most ioctls. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
Bruce Evans 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? No. Or should we just put the appropriate commands in rc.local ? The problem has been moved to putting them in devfs. I'm pretty sure you can change it in the source code for the device node itself. Unfortunately, it's not handled with a marker-and-data approach, which would let you modify it in the object files, even for node instances that would not normally be created at boot time (using an ELF librarian and a linker set). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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 [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
In message [EMAIL PROTECTED], Robe rt Watson writes: 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. Dima is actually working on this problem right now, and he has sent me a prototype which shows great promise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sun, 21 Apr 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: 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. Dima is actually working on this problem right now, and he has sent me a prototype which shows great promise. This is great news. I look forward to seeing some details on -arch once the prototype is ready. 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
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, Apr 20, 2002 at 03:39:14PM -0600, Lyndon Nerenberg wrote: For the benefit of packet sniffers and other things that only want read-only access to /dev/bpf*, what do people think of adding a 'bpf' group for those programs? This allows bpf devices to be read by programs running with an effective gid of 'bpf' instead of the current requirement for an effective user of root. I've been running this way on many of our servers for several months now, and things like snort, tcpdump, etc., are quite happy with it (under stable). I do this a lot too on systems where it makes sense. But I'm not sure I understand what you are asking to be done. Is it asking too much of an administrator to do, # echo 'sniff:*:80:list of users' /etc/group # chown root:sniff /dev/bpf* # chmod 640 /dev/bpf* To do the appropriate customizations? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, Apr 20, 2002 at 04:02:13PM -0600, Lyndon Nerenberg wrote:
Crist == Crist J Clark [EMAIL PROTECTED] writes:
Crist I do this a lot too on systems where it makes sense. But I'm
Crist not sure I understand what you are asking to be done. Is it
Crist asking too much of an administrator to do,
There are two ways to handle this. One is to modify the ports builds to
conditionally create a 'bpf' group. This requires the ports all agree
on the group, and I don't like the idea of a port install messing with
permissions and ownerships of things in /dev (which aren't sticky across
reboots, anyway). If the OS sets the access policy there cannot be any
confusion.
OK. Now you've really lost me. What do ports have to do with this?
Which ports? None of the sniffing programs I am aware of use
set{g,u}id bits. They rely on the permissions of the user running
them.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
Crist == Crist J Clark [EMAIL PROTECTED] writes:
Crist OK. Now you've really lost me. What do ports have to do with
Crist this? Which ports? None of the sniffing programs I am aware
Crist of use set{g,u}id bits. They rely on the permissions of the
Crist user running them.
Sorry -- keyboard and brain disconnect on my part. What I was trying to
get at was the need to run sniffers as root by default. The fewer
things that need to be run as root, the better (e.g. I don't want snort
and trafdump running as root on my firewalls if I can avoid it).
Programs like snort can attempt to lose uid-0 after opening the bpf
device, but others like tcpdump do not.
As David Wolfskill mentioned in a previous message, this idea is the
same as how the operator group is used for dump. kmem did the same
thing for ps and top.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, Apr 20, 2002 at 04:27:18PM -0600, Lyndon Nerenberg wrote:
Crist == Crist J Clark [EMAIL PROTECTED] writes:
Crist OK. Now you've really lost me. What do ports have to do with
Crist this? Which ports? None of the sniffing programs I am aware
Crist of use set{g,u}id bits. They rely on the permissions of the
Crist user running them.
Sorry -- keyboard and brain disconnect on my part. What I was trying to
get at was the need to run sniffers as root by default. The fewer
things that need to be run as root, the better (e.g. I don't want snort
and trafdump running as root on my firewalls if I can avoid it).
Programs like snort can attempt to lose uid-0 after opening the bpf
device, but others like tcpdump do not.
As David Wolfskill mentioned in a previous message, this idea is the
same as how the operator group is used for dump. kmem did the same
thing for ps and top.
These are actually very different in that they are set{u,g}id commands
(well, ps(1) is not set{u,g}id anymore and is root:wheel owned). The
sniffing tools we've been discussing, and pretty much all of the ones
I've used, tcpdump(1), snort(8), nmap(1), etc., are not. When
tcpdump(1) or one of these ports is installed, there is no reason to
give it any special group ownership. The thing that determines whether
someone can sniff is the {u,g}id of the user executing the
command. The port's Makefile doesn't need to know anything about your
/etc/group; it just installs the file -r-xr-x-r-x root:wheel. The
local administrator simply needs to execute the simple commands I put
in my last mail to give a group sniffing powers. The files'
permissions and ownership are never changed.
Since the ports would really make no use of a preordained 'bpf' group,
I still don't see what purpose it really serves to add one. I really
hesitate to add groups and change default ownerships after seeing the
_steady_ stream of mail that the smmsp:smmsp ownership of
/var/spool/mqueue the sendmail(8) upgrade created.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
Crist J. Clark wrote:
These are actually very different in that they are set{u,g}id commands
(well, ps(1) is not set{u,g}id anymore and is root:wheel owned). The
sniffing tools we've been discussing, and pretty much all of the ones
I've used, tcpdump(1), snort(8), nmap(1), etc., are not. When
tcpdump(1) or one of these ports is installed, there is no reason to
give it any special group ownership. The thing that determines whether
someone can sniff is the {u,g}id of the user executing the
command. The port's Makefile doesn't need to know anything about your
/etc/group; it just installs the file -r-xr-x-r-x root:wheel. The
local administrator simply needs to execute the simple commands I put
in my last mail to give a group sniffing powers. The files'
permissions and ownership are never changed.
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? Or should we just put the appropriate commands in rc.local ?
Besides bpf, this would be useful, for example, for people who want to
change permissions on cd-rom devices to 644 so that non-root users can make
iso images (or give a special group cd burner rights).
Craig
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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 -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
