From owner-freebsd-security@FreeBSD.ORG Thu Sep 7 02:05:20 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DF1816A4DF for ; Thu, 7 Sep 2006 02:05:20 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1289143D4C for ; Thu, 7 Sep 2006 02:05:19 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so70842pye for ; Wed, 06 Sep 2006 19:05:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VHa2kkJZjKzgfPFwTxhrQVXqIN8WAbN7Mz43A2wMgwabl2hBAs6wjIlKEMQzGYcz4TldS2CIwzbKSXDNaH9hcaj3Aszn+ZterCF017dD+BHctoClAOXCq/q02wzOrzMrs+400uSUnoiXbch1kAZVLgwgsOHG/MNzTs/MGt98CCo= Received: by 10.35.39.2 with SMTP id r2mr271087pyj; Wed, 06 Sep 2006 19:05:19 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Wed, 6 Sep 2006 19:05:19 -0700 (PDT) Message-ID: Date: Wed, 6 Sep 2006 21:05:19 -0500 From: "Travis H." To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Thu, 07 Sep 2006 02:46:36 +0000 Subject: comments on handbook chapter X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2006 02:05:20 -0000 ``You do not want to overbuild your security or you will interfere with the detection side, and detection is one of the single most important aspects of any security mechanism. For example, it makes little sense to set the schg flag (see chflags(1)) on every system binary because while this may temporarily protect the binaries, it prevents an attacker who has broken in from making an easily detectable change that may result in your security mechanisms not detecting the attacker at all.'' Wouldn't it be better to detect /and/ prevent an attempt to change the system binaries? It seems to me that advising people to focus on detection rather than prevention is wrong-headed. What are you going to do after you detect the attacker? If it's not "prevent him from doing anything", then I question the intelligence of this approach. Root-level compromises don't always get detected immediately, don't always get caught, and once they're in, the playing field is level, and they are very time-consuming to investigate and clean. For example, I know someone with a rootkit that he can install to flash on an add-in card for a device that has DMA access to main memory. For this reason, I usually recommend on prevention as a first priority, and detection as a second priority. For example, Markus Ranum said he once recompiled ls to reboot if it is run by root. Another trick involves recompiling /bin/sh to check to see if it has a tty (shells spawned by network daemons will generally not). Perhaps there is some way to locate any part of the kernel that performs access control and optionally klog the details, so that any actions which are denied also automatically detect possible intrusions? Hmm, I should mention this to elad efrat, who is doing kauth work on NetBSD... -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484