Re: So, back on the topic of enabling bpf in GENERIC...
This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I am pro. It takes a root compromise to use it anyway, and its usefulness for DHCP and rarpd is too compelling. Perhaps the comments in the GENERIC file could be updated. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
I am pro. It takes a root compromise to use it anyway, and its usefulness for DHCP and rarpd is too compelling. Perhaps the comments in the GENERIC file could be updated. Well, given that I've gotten primarily positive support for this I guess it's time to do it. Warner, do you want to commit a securelevel hack before I throw the switch in GENERIC? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sun, Aug 01, 1999 at 10:17:54AM -0400, Sergey Babkin wrote: Warner Losh wrote: In message 37a3b701.851df...@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. I like this. I'd prefer the default to be that bpf forwards all packets, unless there is a template filter defined. I see no reason to change access to bpf at higher secure levels, because a master filter can be installed at boot time to do this work. Of course we may have an equivalent of 'IPFIREWALL_DEFAULT_TO_ACCEPT' to accomodate this. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 37a3b701.851df...@softweyr.com Wes Peters writes: Do we have a list of all services that use bpf? In the base system, ipfilter et al (ie ipsend(1)), tcpdump, rbootd, rarpd and dhcp. Someone who's got a complete set of ports might like to comment on what ports need bpf. Of these, we need to leave rarpd, dhcp and maybe rbootd running, whilst inhibiting tcpdump and ipfilter (or at least stop them being used to sniff networks)[*]. As I've already mentioned elsewhere, a fairly easy option would be to create a `crippled' BPF - which included a hard-wired filter that only returned broadcast packets and disabled BIOCSETF and maybe BIOCPROMISC. The crippled BPF would be part of GENERIC, and anyone who wanted the full functionality could re-compile without the `CRIPPLED_BPF' flag. Another option would be to have the BPF crippling based on the secure-level (or driven via a specific `raise-only' sysctl). Apart from the hard-wired filters, the code to do this is trivial (though not as trivial as simply blocking bpf_open is securelevel 1). [*] I personally don't believe that the mere presence of bpf is a security hole. By default you need root to activate it (and if someone undesirable has root access, you have other problems). It's also trivially easy to sniff a network from a Windoze PC. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message 37a3b701.851df...@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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
"Jordan K. Hubbard" wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I'm a pro folk. Your machine will have to be compromised before bpf becomes and issue, and once a machine is compromised, it is compromised. The concept of "reducing damage" is an illusion. That's like calling finger a security tool. DHCP is very important nowadays. If anyone wants to delude themselves, they can very well press the "Yes! I want to delude myself." button by removing bpf from the kernel. Besides... is there anyone _seriously_ interested in security using GENERIC? Not that GENERIC is in any way deficient, but why use a kitchen-sink kernel? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". That would mean you can't run a secured DHCP server :( -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote: On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. AFAIK it needs - but rarpd was already mentioned and there are lots of other tools which needs bpf and may reopen bpf. The securelevel is a realy nice feature and I use it often. My problem with it is that I asume the more features are put in the more often users may see that they can't raise it one step higher because of other needs. Maybe a set of sysctls with a switch to off only behavour would be a better way. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sat, 31 Jul 1999, Ben Rosengart wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. The isc dhcp server doesn't support a -SIGHUP reload, which would mean a reboot everytime you wanted to change the config file. For the average ISP this isn't a problem, for someone who uses dhcp to make configuring servers easier (me) this would suck. However that's an administrator's choice and changing the behavior wouldn't be that difficult. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] Christopher Masto writes: : I hope you mean " 1". I often diagnose problems using tcpdump etc., : and I don't think bpf should be broken just because someone wants the : minor "flags can't be turned off" feature of level 1. Flags can't be turned off at level 1, and raw devices cannot be accessed: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing. Notice that raw devices cannot be opened... : It seems to be that disabling bpf is more appropriate for security : level 2 and up, if such a thing is desirable. I'm not sure it is. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. and 3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted. I could see arguments for both levels Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] Bernd Walter writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : That would mean you can't run a secured DHCP server :( No. That would mean you'd have to start DHCP before raising the secure level. *THAT* is acceptible, unless restarting the dhcp server is a normal thing to do. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
"Jordan K. Hubbard" wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Pro: it's not a vulnerability unless somebody has already cracked root. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
"Brian F. Feldman" wrote: On Fri, 30 Jul 1999, Brian F. Feldman wrote: In that case, my argument changes to: "There's no good reason not to have bpf in the GENERIC kernel." And how about having if (securelevel 3) return (EPERM); in bpf_open()? I like this. Nice one, Greenie! ;^) Now stop replying to yourself, it's too much like... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] "Jordan K. Hubbard" writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Zounds good to me. This should be simple enough even *I* could handle it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Matthew Dillon wrote: : consistant with the meaning of "raw devices". : :Disabling bpf it will break rarpd (and also rbootd but it is less :important). I think such a thing should be mentioned in documentation. : :-SB Not if rarpd is started via the rc files... it would hook up to bpf prior to the securelevel being raised. But I agree about the documentation. The various server documentation as well as the inetd documentation should mention that bpf-using servers need to be started from the rc's when securelevel is used. 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? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Jordan K. Hubbard wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I'm a pro folk. Your machine will have to be compromised before bpf becomes and issue, and once a machine is compromised, it is compromised. The concept of reducing damage is an illusion. That's like calling finger a security tool. DHCP is very important nowadays. If anyone wants to delude themselves, they can very well press the Yes! I want to delude myself. button by removing bpf from the kernel. Besides... is there anyone _seriously_ interested in security using GENERIC? Not that GENERIC is in any way deficient, but why use a kitchen-sink kernel? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message 37a25361.34799...@bellatlantic.net Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. That would mean you can't run a secured DHCP server :( -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sat, Jul 31, 1999 at 01:17:44PM -0400, Ben Rosengart wrote: On Sat, 31 Jul 1999, Bernd Walter wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. AFAIK it needs - but rarpd was already mentioned and there are lots of other tools which needs bpf and may reopen bpf. The securelevel is a realy nice feature and I use it often. My problem with it is that I asume the more features are put in the more often users may see that they can't raise it one step higher because of other needs. Maybe a set of sysctls with a switch to off only behavour would be a better way. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Sat, 31 Jul 1999, Ben Rosengart wrote: That would mean you can't run a secured DHCP server :( I think only the client needs BPF. Anyway, you just start the server in the rc files, before securelevel is raised. The isc dhcp server doesn't support a -SIGHUP reload, which would mean a reboot everytime you wanted to change the config file. For the average ISP this isn't a problem, for someone who uses dhcp to make configuring servers easier (me) this would suck. However that's an administrator's choice and changing the behavior wouldn't be that difficult. -- - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, Jul 30, 1999 at 05:42:57PM -0600, Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. I hope you mean 1. I often diagnose problems using tcpdump etc., and I don't think bpf should be broken just because someone wants the minor flags can't be turned off feature of level 1. It seems to be that disabling bpf is more appropriate for security level 2 and up, if such a thing is desirable. I'm not sure it is. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 19990731193410.c18...@cicely8.cicely.de Bernd Walter writes: : Maybe a set of sysctls with a switch to off only behavour would be a : better way. Actually, a better way would be to have the interfaces to the network stack that would handle this stuff w/o needing to resort to bpf. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 19990731154458.a2...@netmonger.net Christopher Masto writes: : I hope you mean 1. I often diagnose problems using tcpdump etc., : and I don't think bpf should be broken just because someone wants the : minor flags can't be turned off feature of level 1. Flags can't be turned off at level 1, and raw devices cannot be accessed: 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems, /dev/mem, and /dev/kmem may not be opened for writing. Notice that raw devices cannot be opened... : It seems to be that disabling bpf is more appropriate for security : level 2 and up, if such a thing is desirable. I'm not sure it is. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. and 3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted. I could see arguments for both levels Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 19990731190814.a18...@cicely8.cicely.de Bernd Walter writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of raw devices. : That would mean you can't run a secured DHCP server :( No. That would mean you'd have to start DHCP before raising the secure level. *THAT* is acceptible, unless restarting the dhcp server is a normal thing to do. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Jordan K. Hubbard wrote: We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Pro: it's not a vulnerability unless somebody has already cracked root. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Brian F. Feldman wrote: On Fri, 30 Jul 1999, Brian F. Feldman wrote: In that case, my argument changes to: There's no good reason not to have bpf in the GENERIC kernel. And how about having if (securelevel 3) return (EPERM); in bpf_open()? I like this. Nice one, Greenie! ;^) Now stop replying to yourself, it's too much like... -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message 9518.933378...@zippy.cdrom.com Jordan K. Hubbard writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of raw devices. : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Zounds good to me. This should be simple enough even *I* could handle it. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Matthew Dillon wrote: : consistant with the meaning of raw devices. : :Disabling bpf it will break rarpd (and also rbootd but it is less :important). I think such a thing should be mentioned in documentation. : :-SB Not if rarpd is started via the rc files... it would hook up to bpf prior to the securelevel being raised. But I agree about the documentation. The various server documentation as well as the inetd documentation should mention that bpf-using servers need to be started from the rc's when securelevel is used. 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? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 37a3b701.851df...@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... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
So, back on the topic of enabling bpf in GENERIC...
We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Thanks, - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Here is a pro vote for enabling BPF in GENERIC: It will let us use a dhcp client in the install programs, this is of tremendous use to many people as DHCP starts to become much more popular. I cannot net install a machine at home since that is on a DHCP cable modem service. Also, if root is compromised on a system, even if you don't have bpf installed you would be a fool to believe that they are not sniffing packets/passwords. At the very least Mr. Pragmatic(sp?) has shown the world the power and flexability of KLDs... I am sure someone could write a KLD to impliment the functionality of a packet sniffer. Also an attacker, once obtaining root, could certainly trojan ftpd/sshd/telnetd/login/whatever. I think disabling bpf for "security reasons" is a false sense of security. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
If root is compromised, that's the only way bpf can be gotten to by default. When root's compromised, if no bpf is available, the mem devices can still be created (if not there) and network queues can be listened to. And can't IFF_PROMISC be turned on too? There's no good reason to not have bpf in at least the boot disk kernel. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
It will let us use a dhcp client in the install programs, this is of tremendous use to many people as DHCP starts to become much more popular. I cannot net install a machine at home since that is on a DHCP cable modem service. Well, just to clarify this, if you're installing a 4.0 snapshot then you can indeed now do so; it will just be a bit savage in that the installation-time lease will be snapshotted into your /etc/rc.conf in order that the box can reboot for the first time with network connectivity. After that, it's a very good idea to build a new kernel with bpf support enabled and change the ifconfig_foo line in your /etc/rc.conf to say "DHCP" instead of the static lease information it will have in it. Then you're set from then on out. My only desire is that this process be made entirely automatic by enabling you to skip that kernel rebuild part. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
There's no good reason to not have bpf in at least the boot disk kernel. It already is. That's not the question under discussion here - we're talking about how to make things work in the post-installation boot scenario. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote: There's no good reason to not have bpf in at least the boot disk kernel. It already is. That's not the question under discussion here - we're talking about how to make things work in the post-installation boot scenario. When did that happen? :) In that case, my argument changes to: "There's no good reason not to have bpf in the GENERIC kernel." - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Matthew Dillon wrote: : But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). Want to post the ocde for it? It would be interesting to see how that was done! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). This doesn't actually help the attacker much, since at that point in time the network drivers wouldn't have been calling the bpf tap points, so it might well have been loaded, but it wouldn't have been _doing_ anything useful. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. I thought that was the over-riding reason for adding bpf to the kernel. Otherwise, BPF is mostly (completely) un-necessary for general purpose computing machines. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: BTW, I wrote this section because a hacker actually installed the bpf : device via the module loader during one of the root compromises at BEST, : a year or two ago. He had gotten it from a hackers cookbook of exploits : which he convieniently left on-disk long enough for our daily backups to : catch it :-). : :This doesn't actually help the attacker much, since at that point in :time the network drivers wouldn't have been calling the bpf tap points, :so it might well have been loaded, but it wouldn't have been _doing_ :anything useful. Whatever it was, it was recording packets. This was a year or so ago, I don't have the code handy. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Nate Williams wrote: This is a clear security vs functionality issue and I need to get a good feel for which "cause" is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. This is by far the preferred solution. I might have the details archived from the dhcp mailing list, but IIRC it boils down to dealing properly with an address of 255.255.255.255. Whoever it was that mentioned it recently on this list clearly had the right idea. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. I believe we decided that this would be the preferred method, yes. I don't think, however, that we decided that this was likely to show up in any reasonable amount of time or that anyone had decided to do the actual work. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] "Jordan K. Hubbard" writes: : It already is. That's not the question under discussion here - we're : talking about how to make things work in the post-installation boot : scenario. I'm in favor of having it in the kernel by default. With one proviso. Any place where we talk about locking down a FreeBSD machine, we'd need to make it explicit that bpf should be turned off when you wish to make it hard for intruders to get packets off your wire in a root compromize situation. I wonder if /dev/bpf should be disabled when secure level is 1 or 2... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". What about the one-way sysctls that have been suggested? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] Alfred Perlstein writes: : What about the one-way sysctls that have been suggested? They need to be implemente dfirst. A quick securelevel 0 in bpf_open would allow many people's objections to bpf in the kernel by default. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". Would you be willing to make this change? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message [EMAIL PROTECTED] "Jordan K. Hubbard" writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of "raw devices". : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". Disabling bpf it will break rarpd (and also rbootd but it is less important). I think such a thing should be mentioned in documentation. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
So, back on the topic of enabling bpf in GENERIC...
We got off onto a big tangent about switches and vlans and stuff and I learned a number of interesting things, don't get me wrong, but we still haven't established any consensus on the trade-offs of enabling bpf. This wasn't meant to be a hypothetical discussion, I'm truly trying to measure the trade-off between enabling bpf and (by some fraction) opening things up to easier attack by sniffers in a root-compromise situation vs not having DHCP work properly at all after installation. This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? Thanks, - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Here is a pro vote for enabling BPF in GENERIC: It will let us use a dhcp client in the install programs, this is of tremendous use to many people as DHCP starts to become much more popular. I cannot net install a machine at home since that is on a DHCP cable modem service. Also, if root is compromised on a system, even if you don't have bpf installed you would be a fool to believe that they are not sniffing packets/passwords. At the very least Mr. Pragmatic(sp?) has shown the world the power and flexability of KLDs... I am sure someone could write a KLD to impliment the functionality of a packet sniffer. Also an attacker, once obtaining root, could certainly trojan ftpd/sshd/telnetd/login/whatever. I think disabling bpf for security reasons is a false sense of security. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
If root is compromised, that's the only way bpf can be gotten to by default. When root's compromised, if no bpf is available, the mem devices can still be created (if not there) and network queues can be listened to. And can't IFF_PROMISC be turned on too? There's no good reason to not have bpf in at least the boot disk kernel. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
It will let us use a dhcp client in the install programs, this is of tremendous use to many people as DHCP starts to become much more popular. I cannot net install a machine at home since that is on a DHCP cable modem service. Well, just to clarify this, if you're installing a 4.0 snapshot then you can indeed now do so; it will just be a bit savage in that the installation-time lease will be snapshotted into your /etc/rc.conf in order that the box can reboot for the first time with network connectivity. After that, it's a very good idea to build a new kernel with bpf support enabled and change the ifconfig_foo line in your /etc/rc.conf to say DHCP instead of the static lease information it will have in it. Then you're set from then on out. My only desire is that this process be made entirely automatic by enabling you to skip that kernel rebuild part. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
There's no good reason to not have bpf in at least the boot disk kernel. It already is. That's not the question under discussion here - we're talking about how to make things work in the post-installation boot scenario. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote: There's no good reason to not have bpf in at least the boot disk kernel. It already is. That's not the question under discussion here - we're talking about how to make things work in the post-installation boot scenario. When did that happen? :) In that case, my argument changes to: There's no good reason not to have bpf in the GENERIC kernel. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Brian F. Feldman wrote: On Fri, 30 Jul 1999, Jordan K. Hubbard wrote: There's no good reason to not have bpf in at least the boot disk kernel. It already is. That's not the question under discussion here - we're talking about how to make things work in the post-installation boot scenario. When did that happen? :) In that case, my argument changes to: There's no good reason not to have bpf in the GENERIC kernel. And how about having if (securelevel 3) return (EPERM); in bpf_open()? Here's a nice, relevant excerpt from security(7): SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS If an attacker breaks root he can do just about anything, but there are certain conveniences. For example, most modern kernels have a packet sniffing device driver built in. Under FreeBSD it is called the `bpf' device. An intruder will commonly attempt to run a packet sniffer on a compromised machine. You do not need to give the intruder the capability and most systems should not have the bpf device compiled in. But even if you turn off the bpf device, you still have /dev/mem and /dev/kmem to worry about. For that matter, the intruder can still write raw devices. Also, there is another kernel feature called kldload(8). An enterprising intruder can use a KLD module to install his own bpf de- vice or other sniffing device on a running kernel. To avoid these prob- lems you have to run the kernel at a higher secure level, at least se- curelevel 1. The securelevel can be set with a sysctl on the kern.se- curelevel variable. Once you have set the securelevel to 1, write access to raw devices will be denied and special chflags flags, such as `schg', will be enforced. You must also ensure that the `schg' flag is set on critical startup binaries, directories, and script files - everything that gets run up to the point where the securelevel is set. This might be overdoing it, and upgrading the system is much more difficult when you operate at a higher secure level. You may compromise and run the system at a higher secure level but not set the schg flag for every system file and directory under the sun. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Matthew Dillon wrote: : But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). Want to post the ocde for it? It would be interesting to see how that was done! -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: But even if you turn off the bpf device, you still have /dev/mem and : /dev/kmem to worry about. For that matter, the intruder can still write : raw devices. Also, there is another kernel feature called kldload(8). BTW, I wrote this section because a hacker actually installed the bpf device via the module loader during one of the root compromises at BEST, a year or two ago. He had gotten it from a hackers cookbook of exploits which he convieniently left on-disk long enough for our daily backups to catch it :-). This doesn't actually help the attacker much, since at that point in time the network drivers wouldn't have been calling the bpf tap points, so it might well have been loaded, but it wouldn't have been _doing_ anything useful. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. I thought that was the over-riding reason for adding bpf to the kernel. Otherwise, BPF is mostly (completely) un-necessary for general purpose computing machines. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: BTW, I wrote this section because a hacker actually installed the bpf : device via the module loader during one of the root compromises at BEST, : a year or two ago. He had gotten it from a hackers cookbook of exploits : which he convieniently left on-disk long enough for our daily backups to : catch it :-). : :This doesn't actually help the attacker much, since at that point in :time the network drivers wouldn't have been calling the bpf tap points, :so it might well have been loaded, but it wouldn't have been _doing_ :anything useful. Whatever it was, it was recording packets. This was a year or so ago, I don't have the code handy. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Nate Williams wrote: This is a clear security vs functionality issue and I need to get a good feel for which cause is ascendent here in knowing which way to jump on the matter. Can we now hear the closing arguments from the pro and con folks? I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. This is by far the preferred solution. I might have the details archived from the dhcp mailing list, but IIRC it boils down to dealing properly with an address of 255.255.255.255. Whoever it was that mentioned it recently on this list clearly had the right idea. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. I believe we decided that this would be the preferred method, yes. I don't think, however, that we decided that this was likely to show up in any reasonable amount of time or that anyone had decided to do the actual work. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 8605.933365...@zippy.cdrom.com Jordan K. Hubbard writes: : It already is. That's not the question under discussion here - we're : talking about how to make things work in the post-installation boot : scenario. I'm in favor of having it in the kernel by default. With one proviso. Any place where we talk about locking down a FreeBSD machine, we'd need to make it explicit that bpf should be turned off when you wish to make it hard for intruders to get packets off your wire in a root compromize situation. I wonder if /dev/bpf should be disabled when secure level is 1 or 2... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
On Fri, 30 Jul 1999, Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. What about the one-way sysctls that have been suggested? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message pine.bsf.3.96.990730194407.20420v-100...@cygnus.rush.net Alfred Perlstein writes: : What about the one-way sysctls that have been suggested? They need to be implemente dfirst. A quick securelevel 0 in bpf_open would allow many people's objections to bpf in the kernel by default. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. Would you be willing to make this change? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 9518.933378...@zippy.cdrom.com Jordan K. Hubbard writes: : There are no security levels 3. I'd be happy with 0. This is : consistant with the meaning of raw devices. : : Would you be willing to make this change? Yes. I will make this change tomorrow unless there is significant objections that cannot be resolved in the mean time. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
:In message 9518.933378...@zippy.cdrom.com Jordan K. Hubbard writes: :: There are no security levels 3. I'd be happy with 0. This is :: consistant with the meaning of raw devices. :: :: Would you be willing to make this change? : :Yes. I will make this change tomorrow unless there is significant :objections that cannot be resolved in the mean time. : :Warner It seems to me quite reasonable to prevent further opens of bpf once the secure level has been raised above zero. None of the devices using bpf appear to have a rebinding problem (e.g. as opposed to named running as non-root), so this would fit in well. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. Disabling bpf it will break rarpd (and also rbootd but it is less important). I think such a thing should be mentioned in documentation. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
: consistant with the meaning of raw devices. : :Disabling bpf it will break rarpd (and also rbootd but it is less :important). I think such a thing should be mentioned in documentation. : :-SB Not if rarpd is started via the rc files... it would hook up to bpf prior to the securelevel being raised. But I agree about the documentation. The various server documentation as well as the inetd documentation should mention that bpf-using servers need to be started from the rc's when securelevel is used. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
In message 37a25361.34799...@bellatlantic.net Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
