From owner-freebsd-security@FreeBSD.ORG Wed Sep 29 14:51:56 2004 Return-Path: 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 C0CE016A4CE for ; Wed, 29 Sep 2004 14:51:56 +0000 (GMT) Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15EFA43D3F for ; Wed, 29 Sep 2004 14:51:56 +0000 (GMT) (envelope-from d.m.pick@qmul.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by mail2.qmul.ac.uk with esmtp (Exim 4.14) id 1CCfo7-0006AE-8P; Wed, 29 Sep 2004 15:51:51 +0100 Received: from localhost ([127.0.0.1] helo=xi.css.qmw.ac.uk) by xi.css.qmw.ac.uk with esmtp (Exim 3.34 #1) id 1CCfo7-000Kb9-00; Wed, 29 Sep 2004 15:51:51 +0100 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Deepak Jain In-reply-to: Your message of "Tue, 28 Sep 2004 18:50:39 EDT." <4159EABF.3030004@ai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Sep 2004 15:51:51 +0100 From: David Pick Message-Id: X-Sender-Host-Address: 138.37.8.11 X-QM-Scan-Virus: virusscan says the message is clean X-QM-Scan-Virus: ClamAV says the message is clean cc: freebsd-security@FreeBSD.ORG cc: dwbear75@gmail.com cc: cjclark@alum.mit.edu cc: Alexander Langer Subject: Re: Kernel-loadable Root Kits X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 14:51:56 -0000 > > Thanks for the module, I think its a good idea to commit it to FreeBSD > for a few reasons: > > 1) Some folks just prefer more static kernels. > > 2) Securelevel is a great thing, but can be a pain to do upgrades around > remotely. [A lot of folks use FreeBSD simply because its a breeze to run > remotely]. > > 3) Until someone writes code to add modules to a kernel via /dev/mem and > releases it to the script kiddie world, the bar has been effectively > raised for 99% of the miscreants out there. > > 4) Marketing-wise, it will make folks who don't understand the issues > very deeply more comfortable. And as in #3, that is probably a 99% > accurate feeling. > > 5) For those of us using automatic updating systems, having modules and > kernels out of sync is bad potentially, so NO_KLD helps keep that from > being an issue. 6) securelevel *is* a great thing but sysadmins are tied to the hierarchy of levels chosen by the project, and one size does *not* fit all. As a more general mechanism I would suggest that there is a kernel-build option for *each* facility that can be locked by securelevel, which geves the level at which that facility becomes locked. Then, someone who builds a kernel can choose the hierarchy for themselves. Of course, the defaults for the options would give the existing behaviour. The net result would be a much more flexible mechanism that would allow someone to choose just which facilities they want available or not at run-time. Just as an example I would like to allow firewall rule-sets to be changed but disallow module loading (after bootup). Think of it as a kernel-build-time capability system. -- David Pick