From owner-freebsd-hackers Fri Jul 30 13:23:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id A56A814ED1 for ; Fri, 30 Jul 1999 13:23:08 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id QAA07660; Fri, 30 Jul 1999 16:21:35 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 30 Jul 1999 16:21:35 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.org Subject: Re: So, back on the topic of enabling bpf in GENERIC... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 _ __ ___ ____ ___ ___ ___ > green@FreeBSD.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | > http://www.FreeBSD.org/ _ |___/___/___/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message