From owner-freebsd-security Thu Sep 16 7: 9:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 706AA15464 for <security@FreeBSD.ORG>; Thu, 16 Sep 1999 07:09:33 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA01927; Thu, 16 Sep 1999 07:09:28 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda01925; Thu Sep 16 07:09:11 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA06535; Thu, 16 Sep 1999 07:09:09 -0700 (PDT) Message-Id: <199909161409.HAA06535@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdzv6531; Thu Sep 16 07:09:00 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> X-OS: FreeBSD 3.2-RELEASE X-Sender: cy To: Brett Glass <brett@lariat.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, Harry_M_Leitzell@cmu.edu, security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Wed, 15 Sep 1999 20:12:54 MDT." <4.2.0.58.19990915200910.048dba50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Sep 1999 07:09:00 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.19990915200910.048dba50@localhost>, Brett Glass writes: > At 09:21 AM 9/16/99 +1000, Darren Reed wrote: > > >If the machine is rooted, you're fucked anyway, unless it's so wired > >down with things using file flags that you can't even use vi any more. > > Well, setting securelevel and making certain key files, like the kernel, > immutable helps immensely. > > Say, there's a thought. Would it be possible to make a high security > level "lock down" BPF? Or would it be possible to disable it via > a kernel config option? One could run the kernel configuration > utility to enable or disable it at boot. How about a compromise? Leave BPF in the generic kernel but add a boot option to disable it, then a site can create a loader.conf to to disable it. To enable it an intruder would have to modify loader.conf and reboot. This would surely be noticed -- noticed as much as an intruder building a new kernel with BPF and rebooting. This approach will have the advantage of leaving BPF disabled even after an upgrade. To satisfy any new install requirements, create a sysinstall option or question to disable it during install. We could even create a make.conf option to add this option to loader.conf during make installworld. Personally, I don't see why people are so impassioned about this. I and my team build a custom kernels for each FreeBSD, Tru64 UNIX, and Linux system we maintain and usually maintain custom /etc/system files for our Solaris boxes. We put in the kernel only what the kernel will use on a system, making the kernel as small as possible. Normally we disable BPF, however in cases where customers (usually developers) have many complaints about inaccessibility of a host or service, we turn on BPF, as it helps diagnose problems much more quickly. If you build custom kernels, as I think one should, this whole issue is irrelevant. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message