From owner-freebsd-security Sun Aug 31 14:18:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA18867 for security-outgoing; Sun, 31 Aug 1997 14:18:36 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA18862 for ; Sun, 31 Aug 1997 14:18:32 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id RAA12554; Sun, 31 Aug 1997 17:18:10 -0400 (EDT) Date: Sun, 31 Aug 1997 17:18:08 -0400 (EDT) From: Brian Mitchell To: cschuber@uumail.gov.bc.ca cc: Andrew Brown , BUGTRAQ@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: DDB/securelevel In-Reply-To: <199708311847.LAA03326@cwsys.cwent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 31 Aug 1997, Cy Schubert wrote: > There's a lot to be said about physical security. If one has a sensitive > application, physically secure the machine. > > Secondly, DDB should not be compiled into the kernel of a production > machine unless you are trying to resolve a software or hardware problem. > Once a problem is resolved, remove the option from the kernel config, not > only for security reason but to generally improve performance. I, for > example don't include the KTRACE or bpfilter options for a production > machine unless I am trying to solve a problem. Most security publications > and auditors agree that removing bpfilter can improve network security. > Removing these options on a production machine can also improve performance > because the kernel is not executing rarely used code What _possible_ improvement in security does removing ktrace offer? There is absolutely none, that I can determine. (Note: Most of what ktrace does can be done via shared libraries).