From owner-freebsd-security@FreeBSD.ORG Fri Sep 7 01:31:13 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 268C7106566C for ; Fri, 7 Sep 2012 01:31:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFDE38FC0A for ; Fri, 7 Sep 2012 01:31:12 +0000 (UTC) Received: by obbun3 with SMTP id un3so4696016obb.13 for ; Thu, 06 Sep 2012 18:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OQZzq2ph1dz5kpEgW8Lb/mvLMHqC9u/kmtJ51DikN5c=; b=TzImncmt/gFVMFaAM2pBggZZlpQZPncyUe3gsuBpPGnT7+s2oRIQlt3fIRA2+Ai+Uf Xx4PGz71gzJF+4voRbRvi5L6L95sXcjC+NqfRnf/gB6rR6ekfhwNOF01fPH6SKdA+yaX YN3FlLKhPnUSUvyw/ynuUraO/iN61IkIqnGiHlkWN++MFIoHl83m33m/zKWT40LGBNWR pxhmhylD0C+Ki+Jx7sECzXK3Nz3j5KTLId6gjJTZmxaEBiTV21j86BUukzV7fccHNHav 7Dl7j6KJnFwHWAj8PtutejyMG+pCP5GcRwMB2ncDVye3Jn9V04VkNsY9ny+WAIFKZUua al6Q== Received: by 10.60.30.101 with SMTP id r5mr4186118oeh.68.1346981472224; Thu, 06 Sep 2012 18:31:12 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id a6sm2841827oeh.1.2012.09.06.18.31.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2012 18:31:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120906190239.GG13179@dragon.NUXI.org> Date: Thu, 6 Sep 2012 19:31:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1A362209-58C1-47A0-A10D-F68359051312@bsdimp.com> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <1346951961.59094.158.camel@revolution.hippie.lan> <20120906190239.GG13179@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnfAhROp/juoNcB/vw2FaRdK3Bq5GLce+OzAYHHl5KeWmImcv4pgl8uwrCYJt6cvhJ7UrRO X-Mailman-Approved-At: Fri, 07 Sep 2012 01:36:42 +0000 Cc: Arthur Mesh , Ian Lepore , Doug Barton , freebsd-rc@freebsd.org, freebsd-security@freebsd.org Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 01:31:13 -0000 On Sep 6, 2012, at 1:02 PM, David O'Brien wrote: > On Thu, Sep 06, 2012 at 11:19:21AM -0600, Ian Lepore wrote: >> The kenv application may be available, but on any platform that >> lacks /boot/loader it's likely to produce empty output. Because the >> kernel environment is typically empty, an embedded system may not = even >> have the kenv binary installed. =20 >=20 > The FreeBSD kernel expects to be loaded by /boot/loader and for it to > provided a suitable environment. >=20 > If one has chosen to not use /boot/loader (or include 'kenv' on their > embedded boot media), they're already gone so far down the path of > customization that hacking 'initrandom' should be expected. Really? I don't think so. Most of the ARM and MIPS ports can't be = loaded by /boot/loader, the notable exception being the Marvell ARM = stuff. And even if they were, they lack the code to get the metadata = blobs you need to recover the kenv. It is typical in the embedded space = not to be loaded by /boot/loader. Your gear from $WORK is atypical = here. Besides, kenv typically is static for any given machine, so is = not a good 'randomization' vector. >> I should note that I don't think the needs of embedded systems should >> carry so much weight in this discussion that it leads to jumping = through >> major hoops. >=20 > :-) >=20 >> I think the most important point would be "Let failures be >> soft ones" -- things you may think of as basic tools always available = on >> a minimal installation may not be there on a stripped down embedded >> system; no big deal, just don't hang the system or anything else dire = in >> that case. >=20 > I think that just adds to needless cruft in /etc/rc.d scripts that is > hard to test and keep working -- as committers will 99.9999% time be > in a full FreeBSD environment. >=20 > I don't want to see every command in better_than_nothing() turn into > "test -x ___ && ___". Since kenv is a bad source of entropy, I'm kinda guessing this is moot. Warner=