From owner-freebsd-security@FreeBSD.ORG Mon Sep 11 16:17:50 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 3EDA016A40F for ; Mon, 11 Sep 2006 16:17:50 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E756243D66 for ; Mon, 11 Sep 2006 16:17:46 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (nunefe@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k8BGHdqH072687; Mon, 11 Sep 2006 18:17:45 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k8BGHdE9072686; Mon, 11 Sep 2006 18:17:39 +0200 (CEST) (envelope-from olli) Date: Mon, 11 Sep 2006 18:17:39 +0200 (CEST) Message-Id: <200609111617.k8BGHdE9072686@lurza.secnetix.de> From: Oliver Fromme To: freebsd-security@FreeBSD.ORG, arne_woerner@yahoo.com In-Reply-To: <20060908175046.71795.qmail@web30313.mail.mud.yahoo.com> X-Newsgroups: list.freebsd-security User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 11 Sep 2006 18:17:45 +0200 (CEST) Cc: Subject: Re: comments on handbook chapter X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-security@FreeBSD.ORG, arne_woerner@yahoo.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2006 16:17:50 -0000 R. B. Riddick wrote: > Bigby Findrake wrote: > > Travis H. wrote: > > > Wouldn't it be better to detect /and/ prevent an attempt to change the > > > system binaries? > > > > That's how I interpret that passage from the handbook - that you should > > detect *and* prevent. I'm not clear on how anyone is interpreting that > > passage to suggest that unequal weight should be given to one side or the > > other (detection vs. prevention). The above passage all but says, "don't > > do X because that will interfere with Y." I just don't see that advice as > > advocating imbalance. > > > Hmm... > > I think, this "schg flag"-thing should be done to all files, but invisible to a > potential attacker... <-- PROTECTION There's no need to make it "invisible". First, it wouldn't add anything to the protection. And second, it could be called a case of "security by obscurity". > When some attacker tries to get write access to that file or to move that file > around or so, it should result in a log message (like "BAD SU on ...")... <-- > DETECTION (I think one of the first messages in this thread suggested that > already...) That can be done with the AUDIT framework that has recently been MFCed to 6-stable. > And removing that flag shouldn't be possible so easy, too. What do you mean, "so easy"? It's not easy. The flag can only be removed if security level < 1. Once the system is running at >= 1, lowering the security level requires a reboot. Please see the init(8) manual page for details. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team