From owner-freebsd-questions@FreeBSD.ORG Thu Feb 25 12:52:20 2010 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1FF41065672 for ; Thu, 25 Feb 2010 12:52:20 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 288AA8FC08 for ; Thu, 25 Feb 2010 12:52:20 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.3/8.14.3) with ESMTP id o1PCpHia020926; Thu, 25 Feb 2010 13:51:17 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.3/Submit) id o1PCpGGj020925; Thu, 25 Feb 2010 13:51:16 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Thu, 25 Feb 2010 13:51:15 +0100 From: Ruben de Groot To: Robert Bonomi Message-ID: <20100225125115.GA20797@ei.bzerk.org> References: <201002250249.o1P2nT9r012045@mail.r-bonomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002250249.o1P2nT9r012045@mail.r-bonomi.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Thu, 25 Feb 2010 13:52:18 +0100 (CET) Cc: luvbeastie@larseighner.com, questions@freebsd.org Subject: Re: how to disable loadable kernel moduels? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 12:52:20 -0000 On Wed, Feb 24, 2010 at 08:49:29PM -0600, Robert Bonomi typed: > > > > > I'm building custom kernels for use in 'hostile' environments -- where I > > > need to enforce "restricted" capabilities, even in the event of malicious > > > 'root' access. (if the bad guy has *physical* access to the machine, I > > > know I'm toast, so I don't try to protect against _that_ in software -- > > > beyond the usual access-control mechnisms, that is.) > > > > > > To accomplish this, I need to (among other things) *completely* disable > > > kernel 'loadable module' functionality. Building the required monolithic > > > kernel is no problem, and by booting from _physical_ read-only media, I > > > can protect against bootloader/kernel/application substitution. I just > > > need to make it "impossible" to add modules to the running system. > > > > I don't see how this is really bullet-proof possible. Anyone with root > > access can edit loader.conf and force a reboot --- or wait until a power > > interuption or something causes a reboot. > > You're not thinking 'creatively' enough. heheh :) > superuser access _doesn't_ help if things like 'loader.conf' are on _read-only_ > media. Not just a mount switch, but -hardware- enforced. Many SCSI disks have > a 'write-protect' jumper on them. The _only_ way to defeat =that= requires > physical access to the machine. You probably have covered this allready, but consider running all services in a jailed environment, without access to hardware devices (including [k]mem, io etc). With access to /dev/mem, a sufficiently sophisticated attacker can potentially patch your running kernel on the fly. Ruben