Date: Wed, 3 Feb 1999 00:43:13 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mark Newton <newton@camtech.com.au> Cc: jkh@zippy.cdrom.com, jmb@FreeBSD.ORG, woodford@cc181716-a.hwrd1.md.home.com, security@FreeBSD.ORG Subject: Re: tcpdump Message-ID: <Pine.BSF.3.96.990203003728.21838D-100000@fledge.watson.org> In-Reply-To: <199902030505.PAA19809@frenzy.ct>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Feb 1999, Mark Newton wrote: > Robert Watson wrote: > > > As Matt points out, the security limitations are not very clear: the > > securelevel code generally requires a lot of modifications to the base > > system, so my temptation is to ignore the issue, but create a securelevel > > man page that discusses "things to do in making a securelevel-friendly > > system", and add to it: disable bpf. > > In case this hasn't already been suggested (and apologies if it has): > Make opens on /dev/bpf* fail if securelevel > 0 It has been suggested, but I'm not sure that there are adequate advantages to this method. Let us consider two cases: a) dhcpd or dhclient is run *before* bumping securelevel so that it may continue to use bpf afterwards. This increases the running of risky code before securelvels are enacted, and if the daemon dies, you have to reboot. b) Nasty malicious process comes along after securelevel is bumped, and attaches to dhcpd/dhclient with a debugger to take advantage of it, or manipulates its cache files, etc. In both cases, securelevels and this feature alone have not helped you. Keep in mind that securelevels are designed to protect the kernel against root users, not to prevent access to the network layer. It is not clear to me that the desired bpf functionality is consistent with the goals of securelevels, nor that it may be implemented in a consistent way. Bpf does not put the kernel at risk (except if we're running entirely diskless, and I suspect that then your protocols should be protecting you, not the lack of sniffing via Bpf). All it takes is one host on an ethernet broken into to render the bpf protection useless on any host. I suggest we restrict securelevels to preventing the installation trojan horses and manipulation of base system files. Securelevels are generally not about protecting the running system against attacks in as much as limiting the damage in the long run. Without adding yet more features (protected processes, etc) the Bpf restriction is fairly useless (see a above); let's first implement those others and then see how Bpf fits into the scheme once the framework is in place. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990203003728.21838D-100000>