Date: Sun, 01 Aug 1999 10:17:54 -0400 From: Sergey Babkin <babkin@bellatlantic.net> To: Warner Losh <imp@village.org> Cc: Wes Peters <wes@softweyr.com>, Matthew Dillon <dillon@apollo.backplane.com>, "Brian F. Feldman" <green@FreeBSD.ORG>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, hackers@FreeBSD.ORG Subject: Re: So, back on the topic of enabling bpf in GENERIC... Message-ID: <37A45712.58700F7B@bellatlantic.net> References: <37A3B701.851DF00B@softweyr.com> <Pine.BSF.4.10.9907301619280.6951-100000@janus.syracuse.net> <199907302342.RAA85088@harmony.village.org> <37A25361.34799F96@bellatlantic.net> <199907310140.SAA95581@apollo.backplane.com> <199908010416.WAA95811@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: > > In message <37A3B701.851DF00B@softweyr.com> Wes Peters writes: > : Do we have a list of all services that use bpf? I'm willing to edit the man > : pages, given a list. I guess I could just grep-o-matic here, huh? > > Yes. I'm also in a holding off pattern until we know the exact impact > for all daemons that use this... I think I found a solution that may be better (although more complicated): Let the sysadmin to define a bpf filter for the packets that are considered OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for normal functioning). Provide some typical examples. After this filter is defined and the system goes to a higher security level bpf first applies this filter to all the incoming packets, and only if they pass this filter they are checked for application-specified filters. If there is no such "master" filter defined then bpf can just deny new open()s as proposed earlier. This will allow the applications to use bpf but only for the purposes defined in the master filter. This also resolves the problem of services re-opening bpf after SIGHUP. And speaking on the issue of bpf enabled in GENERIC, I'm strongly pro it. Having bpf disabled is a big pain. May be it would be better to provide a separate prototype configuration file, say, SECURE with all the dangerous things disabled and explanations why they are disabled, so that peoples will think twice before re-enabling them. -SB 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?37A45712.58700F7B>