From owner-freebsd-arch Fri Jun 15 13: 4:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8EE3337B408; Fri, 15 Jun 2001 13:04:31 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f5FK4If52248; Fri, 15 Jun 2001 16:04:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 15 Jun 2001 16:04:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Smith Cc: Peter Pentchev , arch@freebsd.org, audit@freebsd.org Subject: Re: new kldpath(8): display/modify the module search path In-Reply-To: <200106152010.f5FKAoT01353@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 15 Jun 2001, Mike Smith wrote: > IMO, ldconfig shouldn't check, and neither should kldconfig. However, > my principal encouragement here is to make kldconfig behave as much like > ldconfig as possible (where it makes sense), so yes, go ahead and check, > but don't be deluded into thinking this actually offers any real > security. My feeling here is that UNIX is about letting people shoot themselves in the feet--or alternatively, not hard-coding policy when we don't know everything about the environments where it will be used. I'd prefer we: 1) Ship with only secure directories are in the kernel and library paths. 2) Modify the daily security script to detect when that's not the case. 3) Un-modify ldconfig to perform the check, and not make similar kld tools do the check. It's a bit like all of the following: 1) We let people add stuff to LD_LIBRARY_PATH if they want. 2) We let people add stuff to their normal path if they want. 3) We let people put /bin/sh in an inetd.conf line if they want. 4) We let people put null password entries in the file, have multiple users with uid 0, ... We just don't do this by default, and in many cases provide warnings. Once we support MAC, then we can provide a twiddle that will allow the admin to mandatorily *prevent* users from doing stupid things. But having partial hacks everywhere that implement a tiny fraction of anything useful just unnecessarily breaks things in unexpected ways. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message