From owner-cvs-all@FreeBSD.ORG Tue Nov 1 00:32:57 2005 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B1816A420; Tue, 1 Nov 2005 00:32:56 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B791043D69; Tue, 1 Nov 2005 00:32:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA10Wgxq023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Oct 2005 16:32:43 -0800 Message-ID: <4365BD2B.2000404@root.org> Date: Sun, 30 Oct 2005 22:43:55 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam McDougall References: <200510271734.j9RHYZAk015054@repoman.freebsd.org> <20051030062148.GA76667@dragon.NUXI.org> <20051030105647.GR99857@submonkey.net> <436509D5.3020401@root.org> <20051030224442.GV2998@egr.msu.edu> In-Reply-To: <20051030224442.GV2998@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf DEFAULTS GENERIC X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 00:32:57 -0000 Adam McDougall wrote: > On Sun, Oct 30, 2005 at 09:58:45AM -0800, Nate Lawson wrote: > > Ceri Davies wrote: > >On Sat, Oct 29, 2005 at 11:21:48PM -0700, David O'Brien wrote: > > > >>On Thu, Oct 27, 2005 at 05:34:35PM +0000, John Baldwin wrote: > >> > >>>jhb 2005-10-27 17:34:35 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/i386/conf GENERIC > >>> Added files: > >>> sys/i386/conf DEFAULTS > >>> Log: > >>> Create a default kernel config for i386 and move 'device isa' and > >>> 'device npx' (both of which aren't really optional right now) and > >>> 'device io' and 'device mem' (to preserve POLA for 4.x users upgrading > >>> to 6.0) from GENERIC into DEFAULTS. > >> > >>I may be missing something. I don't quite follow the benefit of the new > >>'DEFAULTS' file. I'm also curious why we don't explicitly 'include' > >>DEFAULTS in GENERIC vs. the new automagic include feature. > > > > > >I was also confused by that. There are also no warnings if DEFAULTS is > >missing, which means that by removing a seemingly unrelated file I get a > >different (read: useless to me) kernel. Does INCLUDE_CONFIG_FILE show > >the contents of DEFAULTS as well? > > A better way would be to make io and mem only compile time options > (default to on). There is no benefit to them being modules. Anyone who > wants to compile with NO_DEVIO or NO_DEVMEM will know why their kernel > stops working. > > FWIW, I appreciate that mem can be a kernel module because that means > I can have one less thing in my kernel that might (historically) lead > to a root exploit, yet I can load it on whim if I already have root for > things such as netstat and lsof on a server not running X. Similar for > procfs on a system that occasionally wants to run truss. I like the idea > of not leaving open access to kernel interfaces that have a history of abuse. > It provides a single extra layer of protection while not requiring the > hassle of recompiling the kernel or clamping down the ability of loading > any kernel modules at all (securelevel, syscall modification). > > A drawback of modifying or deleting DEFAULTS is I expect it to come back > the next time I cvsup, removing my changes. procfs is accessible to ordinary users. /dev/{io,mem} are not (based on the default permissions), and if you're not happy with those, change them with devfs or chmod. Or if you're especially paranoid and concerned about root using them, use a MAC policy so only one daemon can access them. I'm also sure there's a great reason for loadable /dev/null besides foot shooting. It's.. um... nope... -- Nate