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