From owner-freebsd-security@FreeBSD.ORG Sun Sep 2 22:20:32 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 3EBDF106564A; Sun, 2 Sep 2012 22:20:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0B99B14EE6C; Sun, 2 Sep 2012 22:20:32 +0000 (UTC) Message-ID: <5043DBAF.40506@FreeBSD.org> Date: Sun, 02 Sep 2012 15:20:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: "David E. O'Brien" References: <201208221843.q7MIhLU4077951@svn.freebsd.org> In-Reply-To: <201208221843.q7MIhLU4077951@svn.freebsd.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - 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: Sun, 02 Sep 2012 22:20:32 -0000 On 08/22/2012 11:43, David E. O'Brien wrote: > Author: obrien > Date: Wed Aug 22 18:43:21 2012 > New Revision: 239569 > URL: http://svn.freebsd.org/changeset/base/239569 > > Log: > Remove old entropy seeding after consumption initializing /dev/random PRNG. > Not doing so opens us up to replay attacks. I object to this change, and would like to see it discussed more. When I did the original implementation of the entropy seeding scripts this issue was discussed, and the decision not to remove the entropy after seeding was deliberate. There are 3 possibilities. First, the system boots normally, gets seeded, and runs for a period of time longer than ($entropy_save_num x cron interval), which by default is 88 minutes. In this case all of the entropy files will be replaced, so the "postrandom" change will be spurious. In the second case, the system boots successfully, gets seeded, but runs for less than the default 88 minutes. In that case there will be at least (uptime / cron interval) new files, and the same number of old files removed. So while some of the entropy will be "stale" at next reboot, it won't all be the same, so even the stale entropy is better than nothing in helping to reseed. In the third case, the system boots, but is then rebooted again before the cron interval has had a chance to replace even 1 file. This is the case where removing the old entropy is particularly pathological. It reduces the available seeding material without adding anything new. From a security perspective, that's worse than the possibility of a replay attack. For all 3 cases, it's important to keep in mind a few things. Primarily, yarrow is designed to avoid exactly the kind of "replay" problem that this change was intended to fix, so it's almost certainly at best unnecessary. Of nearly equal importance it should be kept in mind that we add a non-zero amount of unique material at every boot, so a true replay attack isn't possible, even without this change. In short, this change is at best unnecessary, and possibly detrimental. I'd like to see the postrandom script backed out, but I'll leave it open for others to comment. On a less serious note: > Modified: head/etc/rc.d/random > ============================================================================== > --- head/etc/rc.d/random Wed Aug 22 18:35:17 2012 (r239568) > +++ head/etc/rc.d/random Wed Aug 22 18:43:21 2012 (r239569) > @@ -4,7 +4,7 @@ > # > > # PROVIDE: random > -# REQUIRE: var initrandom > +# REQUIRE: initrandom var This change is spurious, rcorder(8) doesn't care what order they come in. > # BEFORE: netif > # KEYWORD: nojail shutdown > > @@ -14,6 +14,9 @@ name="random" > start_cmd="random_start" > stop_cmd="random_stop" > > +extra_commands="saveseed" > +saveseed_cmd="${name}_stop" I don't understand the need for this. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Sun Sep 2 22:57:41 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B6B841065670; Sun, 2 Sep 2012 22:57:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EAE7D14E33A; Sun, 2 Sep 2012 22:57:13 +0000 (UTC) Message-ID: <5043E449.8050005@FreeBSD.org> Date: Sun, 02 Sep 2012 15:57:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: "David E. O'Brien" References: <201208222337.q7MNbORo017642@svn.freebsd.org> In-Reply-To: <201208222337.q7MNbORo017642@svn.freebsd.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------070804020402040301080703" Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray 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: Sun, 02 Sep 2012 22:57:41 -0000 This is a multi-part message in MIME format. --------------070804020402040301080703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/22/2012 16:37, David E. O'Brien wrote: > Author: obrien > Date: Wed Aug 22 23:37:24 2012 > New Revision: 239598 > URL: http://svn.freebsd.org/changeset/base/239598 > > Log: > * Reinstate r128059's consumption of our best entropy first. > r128060 for "hardware-supplied entropy" reversed this without reason, > seems a typo. I object to this change as well, although mostly for sentimental reasons. :) It's also dubious whether the static /entropy file is really the "best" option at that point, since the "better than nothing" entropy at least contains some elements that have the potential to be different at boot time. > * Isolate "better than nothing" implementation to a function. We generally don't extract code that's only run once into a function, and my stylistic preference is that we do not do that. The attached patch simplifies the script quite a bit, and restores the traditional order of running the "best effort" entropy first. I'm interested in what others think about this. (Note, the patch is easier to understand if you apply it and look at the resulting file.) Doug > Modified: > head/etc/rc.d/initrandom > > Modified: head/etc/rc.d/initrandom > ============================================================================== > --- head/etc/rc.d/initrandom Wed Aug 22 22:48:50 2012 (r239597) > +++ head/etc/rc.d/initrandom Wed Aug 22 23:37:24 2012 (r239598) > @@ -21,6 +21,17 @@ feed_dev_random() > fi > } > > +better_than_nothing() > +{ > + # XXX temporary until we can improve the entropy > + # harvesting rate. > + # Entropy below is not great, but better than nothing. > + # This unblocks the generator at startup > + ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww ) \ > + | dd of=/dev/random bs=8k 2>/dev/null > + cat /bin/ls | dd of=/dev/random bs=8k 2>/dev/null > +} > + > initrandom_start() > { > soft_random_generator=`sysctl kern.random 2>/dev/null` > @@ -52,14 +63,6 @@ initrandom_start() > fi > fi > > - # XXX temporary until we can improve the entropy > - # harvesting rate. > - # Entropy below is not great, but better than nothing. > - # This unblocks the generator at startup > - ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww ) \ > - | dd of=/dev/random bs=8k 2>/dev/null > - cat /bin/ls | dd of=/dev/random bs=8k 2>/dev/null > - > # First pass at reseeding /dev/random. > # > case ${entropy_file} in > @@ -72,6 +75,8 @@ initrandom_start() > ;; > esac > > + better_than_nothing() > + > echo -n ' kickstart' > fi > > -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) --------------070804020402040301080703 Content-Type: text/plain; charset=UTF-8; name="initrandom.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="initrandom.diff" Index: initrandom =================================================================== --- initrandom (revision 240002) +++ initrandom (working copy) @@ -1,8 +1,7 @@ #!/bin/sh -# + # $FreeBSD$ # - # PROVIDE: initrandom # REQUIRE: dumpon ddb # BEFORE: disks @@ -21,8 +20,11 @@ fi } -better_than_nothing() +initrandom_start() { + [ -w /dev/random ] || return + sysctl kern.random 2>/dev/null || return + # XXX temporary until we can improve the entropy # harvesting rate. # Entropy below is not great, but better than nothing. @@ -30,54 +32,36 @@ ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww ) \ | dd of=/dev/random bs=8k 2>/dev/null cat /bin/ls | dd of=/dev/random bs=8k 2>/dev/null -} -initrandom_start() -{ - soft_random_generator=`sysctl kern.random 2>/dev/null` + case ${entropy_file} in + [Nn][Oo] | '') + ;; + *) + feed_dev_random "${entropy_file}" + ;; + esac echo -n 'Entropy harvesting:' - if [ \! -z "${soft_random_generator}" ] ; then + if checkyesno harvest_interrupt; then + ${SYSCTL} kern.random.sys.harvest.interrupt=1 >/dev/null + echo -n ' interrupts' + else + ${SYSCTL} kern.random.sys.harvest.interrupt=0 >/dev/null + fi - if [ -w /dev/random ]; then - if checkyesno harvest_interrupt; then - ${SYSCTL} kern.random.sys.harvest.interrupt=1 >/dev/null - echo -n ' interrupts' - else - ${SYSCTL} kern.random.sys.harvest.interrupt=0 >/dev/null - fi + if checkyesno harvest_ethernet; then + ${SYSCTL} kern.random.sys.harvest.ethernet=1 >/dev/null + echo -n ' ethernet' + else + ${SYSCTL} kern.random.sys.harvest.ethernet=0 >/dev/null + fi - if checkyesno harvest_ethernet; then - ${SYSCTL} kern.random.sys.harvest.ethernet=1 >/dev/null - echo -n ' ethernet' - else - ${SYSCTL} kern.random.sys.harvest.ethernet=0 >/dev/null - fi - - if checkyesno harvest_p_to_p; then - ${SYSCTL} kern.random.sys.harvest.point_to_point=1 >/dev/null - echo -n ' point_to_point' - else - ${SYSCTL} kern.random.sys.harvest.point_to_point=0 >/dev/null - fi - fi - - # First pass at reseeding /dev/random. - # - case ${entropy_file} in - [Nn][Oo] | '') - ;; - *) - if [ -w /dev/random ]; then - feed_dev_random "${entropy_file}" - fi - ;; - esac - - better_than_nothing - - echo -n ' kickstart' + if checkyesno harvest_p_to_p; then + ${SYSCTL} kern.random.sys.harvest.point_to_point=1 >/dev/null + echo -n ' point_to_point' + else + ${SYSCTL} kern.random.sys.harvest.point_to_point=0 >/dev/null fi echo '.' --------------070804020402040301080703-- From owner-freebsd-security@FreeBSD.ORG Sun Sep 2 23:57:19 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D77F1065670 for ; Sun, 2 Sep 2012 23:57:19 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0902A8FC0A for ; Sun, 2 Sep 2012 23:57:18 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3568145wgb.31 for ; Sun, 02 Sep 2012 16:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=tkATNjNk6Q4KijnYM44zBPDT9Jbl9NMdU9ykXCZpgHM=; b=fMiN0Zd1dmKhTUwgB5cIqluqwEmYwOOXjDGAsfjBA0bEE3ggwaekRm2iWvQwXCBNo1 eJ5Fn6s8JnWiMuDVz+It7uwQCYb0Je0bQsBzlncm1koQl36cgzfbedMGe9uVb3re53ZU Iqcn4xmkgcIxAvzr/O/bVl4XwXcFh3nNVVhSHlSPgeJLoP2WcszQIrfic3XY4FILohdi GZTcxMNFkE2hB7i9yhqGJN+ArBZxxD54Ki1Yz3EBrslqt9gJFn3QuqyOnr18N0eEjtNj tuLmaLZAgIEE0c5sXC1h/b9xj3OIBvIwo8+xav928UF/OoMOXfqJGsua1D52RQ4SV2d9 Rk1Q== Received: by 10.180.84.104 with SMTP id x8mr19188268wiy.20.1346630232397; Sun, 02 Sep 2012 16:57:12 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id l5sm23463854wix.5.2012.09.02.16.57.10 (version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 16:57:11 -0700 (PDT) Date: Mon, 3 Sep 2012 00:57:08 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120903005708.7082f230@gumby.homeunix.com> In-Reply-To: <5043DBAF.40506@FreeBSD.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: svn commit: r239569 - 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: Sun, 02 Sep 2012 23:57:19 -0000 On Sun, 02 Sep 2012 15:20:31 -0700 Doug Barton wrote: > On 08/22/2012 11:43, David E. O'Brien wrote: > > Author: obrien > > Date: Wed Aug 22 18:43:21 2012 > > New Revision: 239569 > > URL: http://svn.freebsd.org/changeset/base/239569 > > > > Log: > > Remove old entropy seeding after consumption > > initializing /dev/random PRNG. Not doing so opens us up to replay > > attacks. > > I object to this change, and would like to see it discussed more. No entropy file is effectively equivalent to a known file and anything is better than that. Simply writing out a new version of /entropy would be better. The more significant problem is that initrandom dumps some very low-grade entropy into /dev/random before the entropy file (see below). Since /dev/random has very limited buffering, and processes the buffers in a timed loop, it's almost certain that the first entropy file is completely discarded. IMO the order should be reversed or the low-grade stuff should be piped through sha256. # XXX temporary until we can improve the entropy # harvesting rate. # Entropy below is not great, but better than nothing. # This unblocks the generator at startup ( ps -fauxww; sysctl -a; date; df -ib; dmesg; ps -fauxww ) \ | dd of=/dev/random bs=8k 2>/dev/null cat /bin/ls | dd of=/dev/random bs=8k 2>/dev/null # First pass at reseeding /dev/random. # case ${entropy_file} in [Nn][Oo] | '') ;; *) if [ -w /dev/random ]; then feed_dev_random "${entropy_file}" fi ;; esac From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 00:31:27 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E5F106566B for ; Mon, 3 Sep 2012 00:31:27 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF1FA8FC08 for ; Mon, 3 Sep 2012 00:31:26 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3579092wgb.31 for ; Sun, 02 Sep 2012 17:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=ikQcztaT6UsUW95WnOuZX9epLqO4Rvw7Pzpqjut0nE8=; b=sF8ECkUmr4TuCpg1OS39IHWfs8YA+th+XQjcxe7Dm2ecbmrkSd0PBsstIRcHUl6F24 bSsZtY9+pyVy2nF1/55TjIFhTWItHkryE9+ueJ2pmkQyT1IePbbVP7wKmq4Yx71lAG99 D5nUH1ydJdYHxFRu9yYVjcC5biwlumgoi/ayN5Ig5lGnVc3t5oLS3AErY/nBIlyREpjZ AbvH9ownsKsvcUVg1Qgkl9ePcYgWBpRV/ctGTM1Vo5+jyYfcUErLYXfql04XQnljfqA8 OZsGSYiSBzDhrczy2XK7innK/waieJZ5vv31hw+R7Ot8b7zQX+lp9wVTCBgbWoIi6ehw R0gQ== Received: by 10.180.108.45 with SMTP id hh13mr19362284wib.15.1346632285773; Sun, 02 Sep 2012 17:31:25 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id cl8sm16194184wib.10.2012.09.02.17.31.23 (version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 17:31:24 -0700 (PDT) Date: Mon, 3 Sep 2012 01:31:20 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120903013120.262a34fc@gumby.homeunix.com> In-Reply-To: <20120903005708.7082f230@gumby.homeunix.com> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 00:31:27 -0000 On Mon, 3 Sep 2012 00:57:08 +0100 RW wrote: > On Sun, 02 Sep 2012 15:20:31 -0700 > Doug Barton wrote: > > > On 08/22/2012 11:43, David E. O'Brien wrote: > > > Author: obrien > > > Date: Wed Aug 22 18:43:21 2012 > > > New Revision: 239569 > > > URL: http://svn.freebsd.org/changeset/base/239569 > > > > > > Log: > > > Remove old entropy seeding after consumption > > > initializing /dev/random PRNG. Not doing so opens us up to replay > > > attacks. > > > > I object to this change, and would like to see it discussed more. > > > No entropy file is effectively equivalent to a known file and anything > is better than that. Simply writing out a new version of /entropy > would be better. > > > The more significant problem is that initrandom dumps some very > low-grade entropy into /dev/random before the entropy file (see > below). Since /dev/random has very limited buffering, and processes > the buffers in a timed loop, it's almost certain that the first > entropy file is completely discarded. IMO the order should be > reversed or the low-grade stuff should be piped through sha256. I see that in CURRENT the order is reversed, but it's still repeating the same problem of saturating the buffers. Now most of of the low-grade entropy is going to be lost include the date, which in almost all cases would have eliminated any problem with a reused entropy file. From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 02:18:41 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 9DCFA106566B; Mon, 3 Sep 2012 02:18:41 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE9D8FC14; Mon, 3 Sep 2012 02:18:41 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q832IeHA022921; Sun, 2 Sep 2012 20:18:40 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q832Ic7J039608; Sun, 2 Sep 2012 20:18:38 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Doug Barton In-Reply-To: <5043E449.8050005@FreeBSD.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Sep 2012 20:18:38 -0600 Message-ID: <1346638718.1140.573.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 03 Sep 2012 03:19:08 +0000 Cc: Arthur Mesh , freebsd-security@freebsd.org, freebsd-rc@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: Mon, 03 Sep 2012 02:18:41 -0000 On Sun, 2012-09-02 at 15:57 -0700, Doug Barton wrote: > The attached patch simplifies the script quite a bit, and restores the > traditional order of running the "best effort" entropy first. I'm > interested in what others think about this. (Note, the patch is easier > to understand if you apply it and look at the resulting file.) I have a patchset somewhere that added the ability to supply an alternate command to generate "best effort" entropy. The reason is that the existing code on an embedded system with no realtime clock hardware generates a sequence that sometimes differs by two full bytes from one boot to the next. Often it's identical. Adding insult is the fact that the existing sequence takes about 4-5 seconds on that platform. There just isn't much entropy available there, but I came up with a command sequence that ran in about a second and generated more differences on each boot. I'm still interested in the ability to override the default best effort generator with something else via entries in rc.conf; I'm not picky about the mechanism for doing so. If there's any interest, I'll try to find that old patch I had for it (which I never submitted for fear of starting a "that's not good enough entropy" flame war). -- Ian From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 17:15:50 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 6E6EA1065674; Mon, 3 Sep 2012 17:15:50 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2531A8FC0C; Mon, 3 Sep 2012 17:15:50 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8254772pbb.13 for ; Mon, 03 Sep 2012 10:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=8vlEnwdQBZeMBCNCq88D/Kj40Xe9YUI9ScoTbs1wmps=; b=Nb/2Zjhlv96ocHGGVZWVUk+DspC21LeCCW+y3oeyQ+iBcpiuqgi6gN1+oFV/IrbC1d PiJazy9bYSyV3hibRaNKmMfABtUszlnM9p9NKE6bRkCMJWbtOilgLoIMiaZRULoBk7qQ jT8FYLqGh0bBm+hdhJaoGcCMB/fhl1ifmychOPaSQZ2bZ4h03EWoTNdOUNxxp+Pb6MYe TXQEp5XPyB6JVq1wnOjdOEIJ8Oc+NFBiQGUY7UAqb4wxOwy43OOB7uhSskylY7Gp/N3g Ut9ZXdFdvkVtmZvoThNFtP04MJim20lfb4ZlCX/5jV1r1rVuiLEJ0oTQRen67XF/QA8z u6Hw== Received: by 10.68.242.231 with SMTP id wt7mr39195290pbc.99.1346692544022; Mon, 03 Sep 2012 10:15:44 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id qw6sm10286698pbc.26.2012.09.03.10.15.40 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 10:15:42 -0700 (PDT) Date: Mon, 3 Sep 2012 10:15:38 -0700 From: Arthur Mesh To: Doug Barton Message-ID: <20120903171538.GM1464@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5043DBAF.40506@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 03 Sep 2012 17:30:00 +0000 Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 17:15:50 -0000 Doug, On Sun, Sep 02, 2012 at 03:20:31PM -0700, Doug Barton wrote: > In the third case, the system boots, but is then rebooted again before > the cron interval has had a chance to replace even 1 file. This is the > case where removing the old entropy is particularly pathological. It I believe you're missing the point that we don't just cleanup old entropy file -- we re-generate it via "/etc/rc.d/random fastsaveseed" call in postrandom_start() > > +extra_commands="saveseed" > > +saveseed_cmd="${name}_stop" > > I don't understand the need for this. That's how "/etc/rc.d/random fastsaveseed" translates in to "/etc/rc.d/random stop", which does the jobs of re-generating seed file. In the end, assuming machine boots up passed postrandom script, we're left with no stale seed files, but a freshly generated ${entropy_file_confirmed}, which should be sufficient to seed next bootup. Thanks From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 20:13:28 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 41F8E1065673; Mon, 3 Sep 2012 20:13:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 43664151B6A; Mon, 3 Sep 2012 20:12:26 +0000 (UTC) Message-ID: <50450F2A.10708@FreeBSD.org> Date: Mon, 03 Sep 2012 13:12:26 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Mesh References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> In-Reply-To: <20120903171538.GM1464@x96.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 20:13:28 -0000 On 09/03/2012 10:15, Arthur Mesh wrote: > Doug, > > On Sun, Sep 02, 2012 at 03:20:31PM -0700, Doug Barton wrote: >> In the third case, the system boots, but is then rebooted again before >> the cron interval has had a chance to replace even 1 file. This is the >> case where removing the old entropy is particularly pathological. It > > I believe you're missing the point that we don't just cleanup old > entropy file -- we re-generate it via "/etc/rc.d/random fastsaveseed" call in > postrandom_start() I didn't miss it. What postrandom does is delete all of the (by default) 8 files in /var/db/entropy that were the product of the previous boot's output. Then it re-generates /entropy, which was written out at the last shutdown, ideally after enough uptime for /dev/random to have been properly seeded, with a new file generated from a poorly seeded entropy pool as part of the boot process. IMO both of those are bad ideas, and lower both the quantity and quality of the entropy available at the next boot, should that happen prior to the (again, by default) 88 minutes it takes for the system to update /var/db/entropy. >>> +extra_commands="saveseed" >>> +saveseed_cmd="${name}_stop" >> >> I don't understand the need for this. > > That's how "/etc/rc.d/random fastsaveseed" translates in to "/etc/rc.d/random > stop", which does the jobs of re-generating seed file. Got that now, thanks. > In the end, assuming machine boots up passed postrandom script, we're left with > no stale seed files, but a freshly generated ${entropy_file_confirmed}, which > should be sufficient to seed next bootup. I understand how you're thinking about this, but unfortunately I'm quite certain your thinking is incorrect. As I pointed out in my last message, Yarrow is designed to cope with the possibility of replay attacks, and even with feeding in the same entropy files (after a short boot) the amount of new material we introduce at each boot fully alleviates this concern. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 20:17:05 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E194D1065673; Mon, 3 Sep 2012 20:17:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B216414D927; Mon, 3 Sep 2012 20:17:05 +0000 (UTC) Message-ID: <50451041.9070302@FreeBSD.org> Date: Mon, 03 Sep 2012 13:17:05 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Ian Lepore References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> In-Reply-To: <1346638718.1140.573.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@freebsd.org, freebsd-rc@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: Mon, 03 Sep 2012 20:17:06 -0000 On 09/02/2012 19:18, Ian Lepore wrote: > On Sun, 2012-09-02 at 15:57 -0700, Doug Barton wrote: >> The attached patch simplifies the script quite a bit, and restores the >> traditional order of running the "best effort" entropy first. I'm >> interested in what others think about this. (Note, the patch is easier >> to understand if you apply it and look at the resulting file.) > > I have a patchset somewhere that added the ability to supply an > alternate command to generate "best effort" entropy. The reason is that > the existing code on an embedded system with no realtime clock hardware > generates a sequence that sometimes differs by two full bytes from one > boot to the next. Often it's identical. Adding insult is the fact that > the existing sequence takes about 4-5 seconds on that platform. > > There just isn't much entropy available there, but I came up with a > command sequence that ran in about a second and generated more > differences on each boot. I'm interested in that patch. > I'm still interested in the ability to override the default best effort > generator with something else via entries in rc.conf; I'm not picky > about the mechanism for doing so. If there's any interest, I'll try to > find that old patch I had for it (which I never submitted for fear of > starting a "that's not good enough entropy" flame war). What would probably be useful is to determine what commands are "safe" to run on both kinds of systems and always run those. Then give some additional commands to run by default that can be overridden via an rc.conf flag. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 21:13:19 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 1001D106566B; Mon, 3 Sep 2012 21:13:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 931A014E99E; Mon, 3 Sep 2012 21:13:18 +0000 (UTC) Message-ID: <50451D6E.30401@FreeBSD.org> Date: Mon, 03 Sep 2012 14:13:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Mesh References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> In-Reply-To: <20120903203505.GN1464@x96.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 21:13:19 -0000 On 09/03/2012 13:35, Arthur Mesh wrote: > On Mon, Sep 03, 2012 at 01:12:26PM -0700, Doug Barton wrote: >> I didn't miss it. What postrandom does is delete all of the (by default) >> 8 files in /var/db/entropy that were the product of the previous boot's >> output. Then it re-generates /entropy, which was written out at the last >> shutdown, ideally after enough uptime for /dev/random to have been >> properly seeded, with a new file generated from a poorly seeded entropy >> pool as part of the boot process. > > Yes, except /entropy is generated after /var/db/entropy/* and old > /entropy was fed in to yarrow. So I don't believe saying it's poorly > seeded at that point is fair. It is certainly not likely to be well seeded at that point, especially on low end systems. > On next reboot /entropy will get re-written anyway. ... which illustrates my point that at best the change is superfluous. >> IMO both of those are bad ideas, and lower both the quantity and quality >> of the entropy available at the next boot, should that happen prior to >> the (again, by default) 88 minutes it takes for the system to update >> /var/db/entropy. > > I believe this is better than what we have today, since it prevents a > case where system crashes before cronjob (that writes to > saved-entropy.X) gets to run at all. This patch reduces this window to > matter of a second or so. You're still assuming that feeding the same entropy files in on successive boots is a problem, which hasn't been proven yet. > If you think quantity is very important here, (which I don't believe is > true) I am fine with not deleting /var/db/entropy/* on boot (It doesn't > make things better or worse). > >>> In the end, assuming machine boots up passed postrandom script, we're left with >>> no stale seed files, but a freshly generated ${entropy_file_confirmed}, which >>> should be sufficient to seed next bootup. > >> I understand how you're thinking about this, but unfortunately I'm quite >> certain your thinking is incorrect. As I pointed out in my last message, >> Yarrow is designed to cope with the possibility of replay attacks, and >> even with feeding in the same entropy files (after a short boot) the >> amount of new material we introduce at each boot fully alleviates this >> concern. > > You could be correct about Yarrow, but the Bruce Schneier explicitly > recommends to recycle already used seed with a new one. Reference is > provided in the code. Right, which is why we rotate the files in /var/db/entropy, and write out a new /entropy file as part of the shutdown process. I'm not disagreeing with your premise that new/different entropy files _should_ be used. I'm disagreeing with your premise that deleting/replacing the old ones at boot time is an improvement. > Also, our findings have shown that on some very low end systems, these > seed files are pretty much the only source of entropy early during boot. Hopefully you saw Ian's report along that line. I'm sensitive to the idea of certain low end systems not providing a whole lot of entropy from the commands that are fed in as part of the "better than nothing" process. But it's also useful to note that rc.d/initrandom starts the hardware entropy harvesting process as well, so even though we're not getting a lot of entropy from the "better than nothing" commands we're still stirring the pool with new material early in the boot process. But the fact that on these low end/embedded systems there is very little entropy available at boot time actually makes it more important that we don't delete what little we have. > Moreover, we also uncovered other problems with the way things are > consumed by Yarrow via /dev/random. > We will provide more details on our findings a bit later. Please do ... probably security@ is the right forum for that. Sooner than later if you think that it affects the rc.d related discussion. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 20:35:12 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 D48B41065679; Mon, 3 Sep 2012 20:35:11 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1C38FC2D; Mon, 3 Sep 2012 20:35:11 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8414665pbb.13 for ; Mon, 03 Sep 2012 13:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=tRgi50R3uwNJVO1miTx41Ht6qOuqa5oR7CwH3hQzRDg=; b=FowADcWzhG9pP7wfXWCwsn8ZTg1CUafKKYwNayC9nOPz7hiCQ8ZpeFgRhFprAL5hYx tvFuUs0urgFKL93XXcOcS5I46pzZhoLLfBcbOyugAHLpHkm0lKTEuxnIUS3/Ugrwnq5B yvy/vXwag9Hq+Y9WlRuL4pcDyXZLkfx2ut/EoY19mtVCv/zgI6KYqtpGzG5h4adjzZFZ 4ngEXza4YlDOvmO72jFcvcXp8kahssmmDMNO0wfizfpyTNwEufpubJJBCAJrYwYwjB3U /wLYNkIl4wnvEgFZP1zWljVJjppUYOd1syxLhk4bFv66bX0hycEbmlllsG2Kgbvq+jYA kA9g== Received: by 10.66.77.168 with SMTP id t8mr36356784paw.28.1346704510949; Mon, 03 Sep 2012 13:35:10 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id ka4sm10552381pbc.61.2012.09.03.13.35.08 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 13:35:09 -0700 (PDT) Date: Mon, 3 Sep 2012 13:35:05 -0700 From: Arthur Mesh To: Doug Barton Message-ID: <20120903203505.GN1464@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50450F2A.10708@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 03 Sep 2012 21:32:18 +0000 Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 20:35:12 -0000 On Mon, Sep 03, 2012 at 01:12:26PM -0700, Doug Barton wrote: > I didn't miss it. What postrandom does is delete all of the (by default) > 8 files in /var/db/entropy that were the product of the previous boot's > output. Then it re-generates /entropy, which was written out at the last > shutdown, ideally after enough uptime for /dev/random to have been > properly seeded, with a new file generated from a poorly seeded entropy > pool as part of the boot process. Yes, except /entropy is generated after /var/db/entropy/* and old /entropy was fed in to yarrow. So I don't believe saying it's poorly seeded at that point is fair. On next reboot /entropy will get re-written anyway. > IMO both of those are bad ideas, and lower both the quantity and quality > of the entropy available at the next boot, should that happen prior to > the (again, by default) 88 minutes it takes for the system to update > /var/db/entropy. I believe this is better than what we have today, since it prevents a case where system crashes before cronjob (that writes to saved-entropy.X) gets to run at all. This patch reduces this window to matter of a second or so. If you think quantity is very important here, (which I don't believe is true) I am fine with not deleting /var/db/entropy/* on boot (It doesn't make things better or worse). > > In the end, assuming machine boots up passed postrandom script, we're left with > > no stale seed files, but a freshly generated ${entropy_file_confirmed}, which > > should be sufficient to seed next bootup. > I understand how you're thinking about this, but unfortunately I'm quite > certain your thinking is incorrect. As I pointed out in my last message, > Yarrow is designed to cope with the possibility of replay attacks, and > even with feeding in the same entropy files (after a short boot) the > amount of new material we introduce at each boot fully alleviates this > concern. You could be correct about Yarrow, but the Bruce Schneier explicitly recommends to recycle already used seed with a new one. Reference is provided in the code. Also, our findings have shown that on some very low end systems, these seed files are pretty much the only source of entropy early during boot. Moreover, we also uncovered other problems with the way things are consumed by Yarrow via /dev/random. We will provide more details on our findings a bit later. From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 21:46:44 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4684C106564A; Mon, 3 Sep 2012 21:46:44 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF9F08FC15; Mon, 3 Sep 2012 21:46:43 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8462952pbb.13 for ; Mon, 03 Sep 2012 14:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WWaJC4ut+yrJgKTKOGbORNmc38vQJlI4MqrU4RUPkLY=; b=ZlvZJh03qHe7NM/lLz9TNDwnIOmKK4xYjw1ZEwLxp2qK4lCKaSAl7lr8Kg2pxThbRQ eXxHvNCJm6OP8eAjFHDvXL/dXeu4oZu7fNFjmntXt6QEAL3KX0D67+53V/FHh+AJ6pc3 4Xip2z+7HZLeA+ekOSPUQOlq/Q9jrLo0W3xStsm+7jdgFV8fopTzbbiJb6YMzKIJi65k hk/71gBCj0Fy/ygkgs1dWZ/wAk3RmrAMlTffhME51YMuBzQ9b5NRJMcfBaf5iEWH34Us 3Pj3/TP/h9w/Lun7SrklxiYT4nMLtJRwBpO6tq+fUyABEqEq/GNf/n33pnyQLqhfYOzn WxJw== Received: by 10.68.136.137 with SMTP id qa9mr40592612pbb.140.1346708803533; Mon, 03 Sep 2012 14:46:43 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id vf8sm10661729pbc.27.2012.09.03.14.46.41 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 14:46:42 -0700 (PDT) Date: Mon, 3 Sep 2012 14:46:38 -0700 From: Arthur Mesh To: Doug Barton Message-ID: <20120903214638.GO1464@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50451D6E.30401@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 03 Sep 2012 21:54:40 +0000 Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 21:46:44 -0000 On Mon, Sep 03, 2012 at 02:13:18PM -0700, Doug Barton wrote: > > Yes, except /entropy is generated after /var/db/entropy/* and old > > /entropy was fed in to yarrow. So I don't believe saying it's poorly > > seeded at that point is fair. > > It is certainly not likely to be well seeded at that point, especially > on low end systems. Being seeded with /var/db/entropy/* and /entropy can be considered well seeded, unless you're talking about first boot time. /var/db/entropy/* and /entropy contain entropy from all the entropy collected throughout lifetime of the box. In the best case, they provide 4k + (8*2k) of entropy, assuming each bit provides a bit of entropy. That's plenty enough, given the fact that 128bit of entropy is what's recommended to be seeded with. > > > On next reboot /entropy will get re-written anyway. > > ... which illustrates my point that at best the change is superfluous. I don't believe it's superfluous. I've mentioned a real case where it is an improvement. > > >> IMO both of those are bad ideas, and lower both the quantity and quality > >> of the entropy available at the next boot, should that happen prior to > >> the (again, by default) 88 minutes it takes for the system to update > >> /var/db/entropy. > > > > You're still assuming that feeding the same entropy files in on > successive boots is a problem, which hasn't been proven yet. Yes, in this case, I am assuming the worst case scenario. Perhaps it has not been proven, but I don't think waiting until it is proven is a good idea. Especially since the fix for the potential problem is simple. Also, please consider the fact that Schneier explicitly recommends against reusing same entropy seed files... Consider a system where hardware entropy is disabled (silly but could simulate a case of low-end systems). If I reuse same seed files, I will end up with same exact state of yarrow on both bootups. Bet you if you try to generate RSA SSH hostkeys, you'll end up with identical ones on as in previous boot. > Right, which is why we rotate the files in /var/db/entropy, and write > out a new /entropy file as part of the shutdown process. I'm not > disagreeing with your premise that new/different entropy files _should_ > be used. I'm disagreeing with your premise that deleting/replacing the > old ones at boot time is an improvement. I've mentioned a real case where it is an improvement. > > > Also, our findings have shown that on some very low end systems, these > > seed files are pretty much the only source of entropy early during boot. > > But the fact that on these low end/embedded systems there is very little > entropy available at boot time actually makes it more important that we > don't delete what little we have. I am not simply discarding "little we have". It's seeded in to yarrow before we generate a new /entropy. Thus, for attacker to replicate /entropy, she would probably need to reconstruct "little we had" in the first place. From owner-freebsd-security@FreeBSD.ORG Mon Sep 3 23:00:22 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A3B5E106566C; Mon, 3 Sep 2012 23:00:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4E9BA14E9A5; Mon, 3 Sep 2012 23:00:22 +0000 (UTC) Message-ID: <50453686.9090100@FreeBSD.org> Date: Mon, 03 Sep 2012 16:00:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Mesh References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> In-Reply-To: <20120903214638.GO1464@x96.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - 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: Mon, 03 Sep 2012 23:00:23 -0000 On 09/03/2012 14:46, Arthur Mesh wrote: > On Mon, Sep 03, 2012 at 02:13:18PM -0700, Doug Barton wrote: >>> Yes, except /entropy is generated after /var/db/entropy/* and old >>> /entropy was fed in to yarrow. So I don't believe saying it's poorly >>> seeded at that point is fair. >> >> It is certainly not likely to be well seeded at that point, especially >> on low end systems. > > Being seeded with /var/db/entropy/* and /entropy can be considered well > seeded, unless you're talking about first boot time. /var/db/entropy/* > and /entropy contain entropy from all the entropy collected throughout > lifetime of the box. In the best case, they provide 4k + (8*2k) of entropy, > assuming each bit provides a bit of entropy. That's plenty enough, given > the fact that 128bit of entropy is what's recommended to be seeded with. In an ideal world, that's true. However you brought up one case (first boot) where it isn't. There is also the possibility that the existing files may be of low quality, either due to an active attack, or due to problems with how the device was seeded during the last boot, etc. that we may not be able to rely on all of the assumptions you made above being true. The static files are provided as a means to stir the pool to unblock the device at boot time. But it is "better" (for sufficiently paranoid definitions of "better") to wait as long as possible after boot before actually utilizing the device for something important (like creating a new seed). >>> On next reboot /entropy will get re-written anyway. >> >> ... which illustrates my point that at best the change is superfluous. > > I don't believe it's superfluous. I've mentioned a real case where it is > an improvement. Sorry, I'm being particularly dense here ... can you elaborate on just which case you're referring to? >>>> IMO both of those are bad ideas, and lower both the quantity and quality >>>> of the entropy available at the next boot, should that happen prior to >>>> the (again, by default) 88 minutes it takes for the system to update >>>> /var/db/entropy. >>> >> >> You're still assuming that feeding the same entropy files in on >> successive boots is a problem, which hasn't been proven yet. > > Yes, in this case, I am assuming the worst case scenario. Perhaps it has > not been proven, but I don't think waiting until it is proven is a good > idea. Ummm ... I think you have the logic backwards on this. :) We have a system, designed with fairly thorough knowledge of how Yarrow works, and taking all possible scenarios into account. It's stood the test of time for many years now. You are the one asserting that the system is deficient, the burden is on you to demonstrate the truth of your claims. If you can, then certainly we should take them seriously, and make changes accordingly. But "I think this might be true, therefore we should change stuff" is not good reasoning in any context. It's certainly very bad/dangerous thinking in a security context. > Also, please consider the fact that Schneier explicitly recommends > against reusing same entropy seed files... Yeah, I've covered that. > Consider a system where hardware entropy is disabled (silly but could > simulate a case of low-end systems). If I reuse same seed files, I will > end up with same exact state of yarrow on both bootups. Bet you if you > try to generate RSA SSH hostkeys, you'll end up with identical ones on > as in previous boot. ... and I bet you're wrong. :) Feel free to prove that I'm the one who is actually wrong. Just make sure you preserve the "better than nothing" seed as part of your test case. >>> Also, our findings have shown that on some very low end systems, these >>> seed files are pretty much the only source of entropy early during boot. >> >> But the fact that on these low end/embedded systems there is very little >> entropy available at boot time actually makes it more important that we >> don't delete what little we have. > > I am not simply discarding "little we have". It's seeded in to yarrow > before we generate a new /entropy. Thus, for attacker to replicate > /entropy, she would probably need to reconstruct "little we had" in > the first place. I still think you're fundamentally wrong here, but I have an idea for a compromise that takes your concerns into account without compromising mine. What if, instead of replacing /entropy, we add an additional file in /var/db/entropy at boot time that is numerically 1 higher than $entropy_save_num ? (Note, I have to fix the rotation script to account for this, but I have had "improve the rotation script" on my TODO list for a long time now, and this is a good excuse for me to get a round 'tuit.) That way should the reboot happen before the default 11 minutes that kicks in the cron job we still have fresh entropy to reseed with, and we're not losing anything that we had already. When the rotation script runs it will delete the (IMO) low quality file created at boot, and saved-entropy.1 will be a fresh, clean file with (again, arguably) higher quality entropy that will be used at the next boot time. I briefly considered a different solution like appending to /entropy instead of replacing it, but one of the reasons I'm queasy about touching that file at boot time is that in the event that the system crashes shortly after boot (which happens to those of us who track -current rather often) I don't want the / file system to have been written to. Having the /entropy file written out at shutdown time is a "necessary evil" given that we can't be sure that /var is available in the early stages of rc, I'm not thrilled about compounding the problem by writing to it so early in the boot. What do you think about the idea of adding a new file in /var/db/entropy? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 00:46:27 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA95C106566C for ; Tue, 4 Sep 2012 00:46:27 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79C0E8FC0A for ; Tue, 4 Sep 2012 00:46:26 +0000 (UTC) Received: by weyx56 with SMTP id x56so4018848wey.13 for ; Mon, 03 Sep 2012 17:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=fiGPSAsQd9a8F1FWKKvQvrFEtLU0dDUtl6F1+bbRz98=; b=ehgG35V4LhEh+is65S+Na3a82lBdVd7KE8oVFoZ/GRntooEgbzbGqkxAAF6qYDeDOV yZ+whqwPasirZEvBVM+nWYShTmYXrEbpp/0iUWIdwTmtWuTi5l/wKvOO89fvnLLx12wY QWNRbI8ZJ2Sm8wjjhEpwgEz26LlXq+yxPBPrCuqbzd888vrkpyMrupVON1JU5X6NkQ8M VzhkWuag+ZeDVVW6x2+5FyihB9Uix8KSuYZSnDk7nif6j8ablAOEviauaB4aCAkSTM5h nHWfg7vtKP+uBlvj7Hq5U5N8vA3IbImAeILKy53X49YOk8awBou9vHxQqCgNdntkLmZ/ +0kA== Received: by 10.216.139.196 with SMTP id c46mr10650940wej.220.1346719586007; Mon, 03 Sep 2012 17:46:26 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id l5sm31979517wix.5.2012.09.03.17.46.23 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 17:46:24 -0700 (PDT) Date: Tue, 4 Sep 2012 01:46:21 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120904014621.3f173513@gumby.homeunix.com> In-Reply-To: <20120903203505.GN1464@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 00:46:28 -0000 On Mon, 3 Sep 2012 13:35:05 -0700 Arthur Mesh wrote: > You could be correct about Yarrow, but the Bruce Schneier explicitly > recommends to recycle already used seed with a new one. Reference is > provided in the code. I think this is basically sound, but bear in mind that the yarrow kernel thread, which processes the entropy buffers into yarrow, loops with a 100 ms pause. You have to allow enough time for that delay and additional time for the queues to be drained and the yarrow reseed; otherwise you are discarding the entropy (assuming you haven't already done that by saturating the buffers with sysctl -a). From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 12:28:15 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 4043C1065781; Tue, 4 Sep 2012 12:28:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id ECD948FC1E; Tue, 4 Sep 2012 12:28:14 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 0CBA86B0B; Tue, 4 Sep 2012 14:28:14 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id C789881F3; Tue, 4 Sep 2012 14:28:13 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> Date: Tue, 04 Sep 2012 14:28:11 +0200 In-Reply-To: <50451D6E.30401@FreeBSD.org> (Doug Barton's message of "Mon, 03 Sep 2012 14:13:18 -0700") Message-ID: <86ehmi2cro.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, "David E. O'Brien" , Mark Murray Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 12:28:15 -0000 Doug Barton writes: > Please do ... probably security@ is the right forum for that. Sooner > than later if you think that it affects the rc.d related discussion. Note that unlike other FreeBSD mailing lists, where foo@ is an alias freebsd-foo@, security@ is not an alias for freebsd-security@, but rather for either secteam@ or so@ (I forget which). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 13:13:48 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 8C3171065678 for ; Tue, 4 Sep 2012 13:13:48 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 204E98FC21 for ; Tue, 4 Sep 2012 13:13:47 +0000 (UTC) Received: by ialo14 with SMTP id o14so11316386ial.13 for ; Tue, 04 Sep 2012 06:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Sjxpv/pKh/mfptSFD5igbO+AIyoqJNJOBrkpsypAI4=; b=h0l1Y2+59UObK25l1g60tFb2gBcnWrVhVPg9l8rA5igdBHAWT9rhcDZfxpSNyZRc0Z sSVc64yfG2O1ExZZis75zr+0PMKTb9vAlqfuLqbjRGyP0l2OFZycsL43qodt7uWSyBEM BtXsYS1JbeFRfmMKgwUpI2ffIeVIvk9OfZH4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6Sjxpv/pKh/mfptSFD5igbO+AIyoqJNJOBrkpsypAI4=; b=fYgknqp0xBhtdJO/Sel8L8PDmxVc6tPmjSPmQNrilnvPaOdTKuNqVz0WHfScGgbZka L3AU3XP36A4wk/RMgxhMUxUKE1tB2aJmJWxOyHAYC/h1aW/+9h055E3rf7asSosB6dLH y6xqa+guKyHYtveREuZB8ZN94P8rEs0us82ZVpyzK9fQWOTMc8BQAq/g7TfJOaBGgiMk jSX87Ft/8LgiAlwDcS0zbS7dIODd8rySqqO+Q3nKFgFqIx8OhXaAwpgcoixipUL8zQJH XnOKuzphAQ1+5V/M6byA/p7fNhvkALxvG9hjI7Nu4HPyeit88SjnEIHjupXL5m2mT1fL cdjA== MIME-Version: 1.0 Received: by 10.60.3.194 with SMTP id e2mr15890544oee.1.1346764426975; Tue, 04 Sep 2012 06:13:46 -0700 (PDT) Received: by 10.76.85.135 with HTTP; Tue, 4 Sep 2012 06:13:46 -0700 (PDT) X-Originating-IP: [89.19.86.154] Received: by 10.76.85.135 with HTTP; Tue, 4 Sep 2012 06:13:46 -0700 (PDT) In-Reply-To: <86ehmi2cro.fsf@ds4.des.no> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <86ehmi2cro.fsf@ds4.des.no> Date: Tue, 4 Sep 2012 14:13:46 +0100 Message-ID: From: "Simon L. B. Nielsen" To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= X-Gm-Message-State: ALoCoQkxq9ElVECBi2HO2WkOpDLGVW4BxF/h27ehO+N/6xt86GEhIO8QEc33YivwLhRp5po0mV70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Arthur Mesh , Doug Barton , freebsd-rc@freebsd.org, freebsd-security@freebsd.org Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 13:13:48 -0000 Security@ is an alias for secteam (to avoid accidentally leaking confidential reports). --=20 Simon L. B. Nielsen Via mobile - sorry about the top posting On 4 Sep 2012 13:29, "Dag-Erling Sm=C3=B8rgrav" wrote: > Doug Barton writes: > > Please do ... probably security@ is the right forum for that. Sooner > > than later if you think that it affects the rc.d related discussion. > > Note that unlike other FreeBSD mailing lists, where foo@ is an alias > freebsd-foo@, security@ is not an alias for freebsd-security@, but > rather for either secteam@ or so@ (I forget which). > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g > " > From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 20:15:21 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D0461065673; Tue, 4 Sep 2012 20:15:21 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C894A8FC19; Tue, 4 Sep 2012 20:15:20 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q84KFJ9Y062280; Tue, 4 Sep 2012 14:15:20 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q84KFHIh041559; Tue, 4 Sep 2012 14:15:17 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Doug Barton In-Reply-To: <50451041.9070302@FreeBSD.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Sep 2012 14:15:17 -0600 Message-ID: <1346789717.1140.675.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 04 Sep 2012 20:39:31 +0000 Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" 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: Tue, 04 Sep 2012 20:15:21 -0000 On Mon, 2012-09-03 at 13:17 -0700, Doug Barton wrote: > On 09/02/2012 19:18, Ian Lepore wrote: > > I have a patchset somewhere that added the ability to supply an > > alternate command to generate "best effort" entropy. The reason is that > > the existing code on an embedded system with no realtime clock hardware > > generates a sequence that sometimes differs by two full bytes from one > > boot to the next. Often it's identical. Adding insult is the fact that > > the existing sequence takes about 4-5 seconds on that platform. > > > > There just isn't much entropy available there, but I came up with a > > command sequence that ran in about a second and generated more > > differences on each boot. > > I'm interested in that patch. Alas, I cannot find the patch itself, just some old notes. It's no great loss... as I remember it the code part was pretty dumb, it just looked for a variable with a name like initrandom_entropy_cmd, and if that variable was not empty it did "eval $initrandom_entropy_cmd" and nothing else; the command itself had to generate data and feed it to /dev/random. In other words, the mechanism was basically "you want control? you've got it". I'm not sophisticated in the ways of rc fu, so it's unlikely I could come up with the best solution, and I'd be happy with anything that would provide more control, whatever the mechanism. I did find some notes that contained the alternative command sequence I was happy with, which was apparently: pscmd="ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl" sccmd="sysctl kern.timecounter.tc kern.cp_times vm.stats" vmcmd="vmstat -Pismz" entropy_cmd="($vmcmd; $sccmd; $pscmd) | tr -Cd '0123456789'" But I've just now realized that vmstat lives in /usr/bin, which maybe won't be mounted at the time this is needed? If so that's too bad, because that set of vmstat parms generates some numbers that are unlikely to be identical from one boot to the next. The sysctl -a in the original initrandom sequence was part of the killer for execution time. On a 180mhz arm chip that command alone takes like 3 seconds, and it generates a lot of unchanging boilerplate text. I remember picking a few select values that had a good chance of being different from one run to the next. The same is true of the parms I used on the ps command, I asked for outputs like "number of involuntary context switches" because even a small difference in the timing of an interrupt occurring during one boot sequence compared to the next can perturb those numbers. Those commands still generated a fair amount of unchanging boilerplate text, and it's mostly the numbers that change, so I fed all the output through tr to strip out everything but the numbers. -- Ian From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:01:28 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id 25AA71065739; Tue, 4 Sep 2012 22:01:28 +0000 (UTC) Date: Tue, 4 Sep 2012 15:01:26 -0700 From: David O'Brien To: Doug Barton Message-ID: <20120904220126.GA85339@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5043E449.8050005@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 22:01:28 -0000 On Sun, Sep 02, 2012 at 03:57:13PM -0700, Doug Barton wrote: > On 08/22/2012 16:37, David E. O'Brien wrote: > > Author: obrien > > Date: Wed Aug 22 23:37:24 2012 > > New Revision: 239598 > > URL: http://svn.freebsd.org/changeset/base/239598 > > > > Log: > > * Reinstate r128059's consumption of our best entropy first. > > r128060 for "hardware-supplied entropy" reversed this without reason, > > seems a typo. > > I object to this change as well, although mostly for sentimental > reasons. :) Hi Doug, Hope you had a good Labor Day Holiday. I'm sorry I didn't see your messages before I committed another change to this file (r240108). I had it ready to commit last Thursday night, but didn't want to commit it before being AFK over the holiday. > It's also dubious whether the static /entropy file is > really the "best" option at that point, since the "better than nothing" > entropy at least contains some elements that have the potential to be > different at boot time. I may be misreading. Are you suggesting you don't have much faith that there is a good amount of entropy in the saved "/entropy" as produced by /dev/random? > > * Isolate "better than nothing" implementation to a function. > > We generally don't extract code that's only run once into a function, > and my stylistic preference is that we do not do that. I'll go thru your messages and take a look at your diff. I think what I committed is a better abstraction. I think the name of the function helps drive the point that that entropy gathering isn't all that good, and makes reading the logic flow of the code easier to read. -- -- David (obrien@NUXI.org) From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:08:08 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51632106566B; Tue, 4 Sep 2012 22:08:08 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id B8F3A8FC18; Tue, 4 Sep 2012 22:08:06 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q84M7x7F049462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Sep 2012 08:07:59 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q84M7sRQ003918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2012 08:07:54 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q84M7soT003917; Wed, 5 Sep 2012 08:07:54 +1000 (EST) (envelope-from peter) Date: Wed, 5 Sep 2012 08:07:54 +1000 From: Peter Jeremy To: Doug Barton Message-ID: <20120904220754.GA3643@server.rulingia.com> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <50453686.9090100@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 22:08:08 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Sep-03 16:00:22 -0700, Doug Barton wrote: >The static files are provided as a means to stir the pool to unblock the >device at boot time. As far as I can tell, this is no longer required. Both the Yarrow and Nehemiah Padlock generators initialise to "seeded" and there is no provision (other than sysctl) to "unseed" them. Yarrow will begin collecting entropy as soon as the random device receives a MOD_LOAD event during kernel startup. >Ummm ... I think you have the logic backwards on this. :) We have a >system, designed with fairly thorough knowledge of how Yarrow works, and >taking all possible scenarios into account. It's stood the test of time >for many years now. Has anyone actually done a security analysis of our random(4)? >What if, instead of replacing /entropy, we add an additional file in >/var/db/entropy at boot time that is numerically 1 higher than >$entropy_save_num ? That sounds like a reasonable idea. > (Note, I have to fix the rotation script to account >for this, but I have had "improve the rotation script" on my TODO list >for a long time now, and this is a good excuse for me to get a round >'tuit.) You might like to look at kern/134225 (which is misfiled, sorry). --=20 Peter Jeremy --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBGe7oACgkQ/opHv/APuIepJQCdFrWX4g0KN1ToSckiakYuInVl PLcAn2Sn0L2/3EBqPiRw8Hs1U7EdcJdy =G90S -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:40:08 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id C4A051065673; Tue, 4 Sep 2012 22:40:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B789F14EFCB; Tue, 4 Sep 2012 22:39:34 +0000 (UTC) Message-ID: <50468326.8070009@FreeBSD.org> Date: Tue, 04 Sep 2012 15:39:34 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: obrien@freebsd.org References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> In-Reply-To: <20120904220126.GA85339@dragon.NUXI.org> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray 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: Tue, 04 Sep 2012 22:40:08 -0000 On 09/04/2012 03:01 PM, David O'Brien wrote: > On Sun, Sep 02, 2012 at 03:57:13PM -0700, Doug Barton wrote: >> On 08/22/2012 16:37, David E. O'Brien wrote: >>> Author: obrien >>> Date: Wed Aug 22 23:37:24 2012 >>> New Revision: 239598 >>> URL: http://svn.freebsd.org/changeset/base/239598 >>> >>> Log: >>> * Reinstate r128059's consumption of our best entropy first. >>> r128060 for "hardware-supplied entropy" reversed this without reason, >>> seems a typo. >> >> I object to this change as well, although mostly for sentimental >> reasons. :) > > > Hi Doug, > Hope you had a good Labor Day Holiday. > > I'm sorry I didn't see your messages before I committed another change to > this file (r240108). Yes, me too. :) > I had it ready to commit last Thursday night, but > didn't want to commit it before being AFK over the holiday. That much is appreciated. Regarding your changes in r240108: 1. Adding kenv to the mix is probably a good idea, however the output of the ps command won't be the same both times it is run, which is why it was in there twice. I'll have to give the kenv output a look. I would also like to confirm that it's available on all platforms. 2. I'm not sure I like the change from cat'ing /bin/ls to the hash of the kern.bootfile output. Given that most users stick with the GENERIC kernel or the same custom kernel on multiple machines I'm not confident that there will be a statistically significant difference in the amount entropy between the 2, and given what Yarrow does to obfuscate the internal entropy state I'm not confident that hashing the input is either necessary or desirable. 3. Given that we're running the same set of commands at each boot, it's not clear to me how changing the order helps, but I don't necessarily disagree with that change. >> It's also dubious whether the static /entropy file is >> really the "best" option at that point, since the "better than nothing" >> entropy at least contains some elements that have the potential to be >> different at boot time. > > I may be misreading. Are you suggesting you don't have much faith that > there is a good amount of entropy in the saved "/entropy" as produced by > /dev/random? I clarified this in subsequent parts of the thread, if I need to clarify further after you have caught up don't hesitate to let me know. >>> * Isolate "better than nothing" implementation to a function. >> >> We generally don't extract code that's only run once into a function, >> and my stylistic preference is that we do not do that. > > I'll go thru your messages and take a look at your diff. Thanks. In case it's not clear, please hold off on any further changes until we have a better consensus on what the changes should be. > I think what I committed is a better abstraction. > I think the name of the function helps drive the point that that entropy > gathering isn't all that good, and makes reading the logic flow of the > code easier to read. I disagree on all points, sorry. But at this time the function is the least of my worries. :) Doug From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:46:23 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id C99E6106564A; Tue, 4 Sep 2012 22:46:23 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id ECB971500B7; Tue, 4 Sep 2012 22:46:22 +0000 (UTC) Message-ID: <504684BE.7070603@FreeBSD.org> Date: Tue, 04 Sep 2012 15:46:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Peter Jeremy References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> In-Reply-To: <20120904220754.GA3643@server.rulingia.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@freebsd.org, freebsd-rc@freebsd.org, Mark Murray Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 22:46:23 -0000 On 09/04/2012 03:07 PM, Peter Jeremy wrote: > On 2012-Sep-03 16:00:22 -0700, Doug Barton wrote: >> The static files are provided as a means to stir the pool to unblock the >> device at boot time. > > As far as I can tell, this is no longer required. It always has been required in the sense that it improves the quality of the random bits during and shortly after boot. > Both the Yarrow and > Nehemiah Padlock generators initialise to "seeded" and there is no > provision (other than sysctl) to "unseed" them. That's a bit of a chimera, and I would prefer that Mark comment on that if he so desires. :) > Yarrow will begin > collecting entropy as soon as the random device receives a MOD_LOAD > event during kernel startup. .... assuming all of the defaults, yes. This is another reason I'm not very concerned about replay attacks. >> What if, instead of replacing /entropy, we add an additional file in >> /var/db/entropy at boot time that is numerically 1 higher than >> $entropy_save_num ? > > That sounds like a reasonable idea. Thanks. I am particularly interested in what David and Arthur have to say about it. >> (Note, I have to fix the rotation script to account >> for this, but I have had "improve the rotation script" on my TODO list >> for a long time now, and this is a good excuse for me to get a round >> 'tuit.) > > You might like to look at kern/134225 (which is misfiled, sorry). I just grabbed that, thanks. I wish someone had brought that to my attention sooner, but there you go. Overall I like the approach, but I may rework the logic a bit. Thank you for suggesting it. Doug From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:47:42 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id B1E8A106566B; Tue, 4 Sep 2012 22:47:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 82E5614FDA4; Tue, 4 Sep 2012 22:47:35 +0000 (UTC) Message-ID: <50468507.1050901@FreeBSD.org> Date: Tue, 04 Sep 2012 15:47:35 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Simon L. B. Nielsen" References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <86ehmi2cro.fsf@ds4.des.no> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Arthur Mesh , freebsd-rc@freebsd.org, freebsd-security@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 22:47:42 -0000 Yes, I know this, that's why I suggested it. :) Of course, if it turns out that the issues are not confidential then sharing them on the public list is preferred. Doug On 09/04/2012 06:13 AM, Simon L. B. Nielsen wrote: > Security@ is an alias for secteam (to avoid accidentally leaking > confidential reports). > > -- > Simon L. B. Nielsen > Via mobile - sorry about the top posting > > On 4 Sep 2012 13:29, "Dag-Erling Smørgrav" > wrote: > > Doug Barton writes: > > Please do ... probably security@ is the right forum for that. Sooner > > than later if you think that it affects the rc.d related discussion. > > Note that unlike other FreeBSD mailing lists, where foo@ is an alias > freebsd-foo@, security@ is not an alias for freebsd-security@, but > rather for either secteam@ or so@ (I forget which). > > DES > -- > Dag-Erling Smørgrav - des@des.no > _______________________________________________ > freebsd-security@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org > " > From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:54:22 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 37A4A106566C; Tue, 4 Sep 2012 22:54:22 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E623A8FC08; Tue, 4 Sep 2012 22:54:21 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id DC7F76D11; Wed, 5 Sep 2012 00:54:20 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 7A9F482D7; Wed, 5 Sep 2012 00:54:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <86ehmi2cro.fsf@ds4.des.no> <50468507.1050901@FreeBSD.org> Date: Wed, 05 Sep 2012 00:54:20 +0200 In-Reply-To: <50468507.1050901@FreeBSD.org> (Doug Barton's message of "Tue, 04 Sep 2012 15:47:35 -0700") Message-ID: <867gs9e6w3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@freebsd.org, "Simon L. B. Nielsen" , freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 22:54:22 -0000 Doug Barton writes: > Yes, I know this, that's why I suggested it. :) Sorry, I thought you meant it should be discussed on freebsd-security as opposed to freebsd-rc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 22:59:46 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 683B5106564A; Tue, 4 Sep 2012 22:59:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0A83214E175; Tue, 4 Sep 2012 22:59:46 +0000 (UTC) Message-ID: <504687E1.3060203@FreeBSD.org> Date: Tue, 04 Sep 2012 15:59:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ian Lepore References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> In-Reply-To: <1346789717.1140.675.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" 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: Tue, 04 Sep 2012 22:59:46 -0000 On 09/04/2012 01:15 PM, Ian Lepore wrote: > On Mon, 2012-09-03 at 13:17 -0700, Doug Barton wrote: >> On 09/02/2012 19:18, Ian Lepore wrote: >>> I have a patchset somewhere that added the ability to supply an >>> alternate command to generate "best effort" entropy. The reason is that >>> the existing code on an embedded system with no realtime clock hardware >>> generates a sequence that sometimes differs by two full bytes from one >>> boot to the next. Often it's identical. Adding insult is the fact that >>> the existing sequence takes about 4-5 seconds on that platform. >>> >>> There just isn't much entropy available there, but I came up with a >>> command sequence that ran in about a second and generated more >>> differences on each boot. >> >> I'm interested in that patch. > > Alas, I cannot find the patch itself, just some old notes. Bummer. > It's no great loss... as I remember it the code part was pretty dumb, it > just looked for a variable with a name like initrandom_entropy_cmd, and > if that variable was not empty it did "eval $initrandom_entropy_cmd" and > nothing else; the command itself had to generate data and feed it > to /dev/random. In other words, the mechanism was basically "you want > control? you've got it". Ok, it should be pretty easy for me to produce that. > I did find some notes that contained the alternative command sequence I > was happy with, which was apparently: > > pscmd="ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl" > sccmd="sysctl kern.timecounter.tc kern.cp_times vm.stats" > vmcmd="vmstat -Pismz" > entropy_cmd="($vmcmd; $sccmd; $pscmd) | tr -Cd '0123456789'" Excellent, thanks! > But I've just now realized that vmstat lives in /usr/bin, which maybe > won't be mounted at the time this is needed? If so that's too bad, > because that set of vmstat parms generates some numbers that are > unlikely to be identical from one boot to the next. With the appropriate amount of >/dev/null involved we can still use that if it's available. Given how common the "one big partition" scheme is nowadays I don't object to trying stuff that's in /usr/ as long as we fail softly if it doesn't exist. Particularly in a case like this where it is likely to be useful. > The sysctl -a in the original initrandom sequence was part of the killer > for execution time. On a 180mhz arm chip that command alone takes like > 3 seconds, and it generates a lot of unchanging boilerplate text. I > remember picking a few select values that had a good chance of being > different from one run to the next. Good info, thanks. > The same is true of the parms I used on the ps command, I asked for > outputs like "number of involuntary context switches" because even a > small difference in the timing of an interrupt occurring during one boot > sequence compared to the next can perturb those numbers. You kids with your fancy ps commands. :) The original version of this was done almost 12 years ago, so I was somewhat limited in what I had available, and even today we are still limited by what's available on all platforms. But I'm glad to see the interest in modernizing this, especially taking embedded systems into better account. > Those commands still generated a fair amount of unchanging boilerplate > text, and it's mostly the numbers that change, so I fed all the output > through tr to strip out everything but the numbers. I'm not sure I agree with that, since the combination of lower quality input (the boilerplate) and higher quality (changing numbers) still provides more bits to stir the pool with. Even though the average quality is lower over the total number of bits I still think it's probably more valuable to pump in the higher quantity given the internal chewing that Yarrow does with the bits. Doug From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 23:00:26 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 685E5106564A; Tue, 4 Sep 2012 23:00:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 23F4B14ED63; Tue, 4 Sep 2012 23:00:26 +0000 (UTC) Message-ID: <50468809.20300@FreeBSD.org> Date: Tue, 04 Sep 2012 16:00:25 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <86ehmi2cro.fsf@ds4.des.no> <50468507.1050901@FreeBSD.org> <867gs9e6w3.fsf@ds4.des.no> In-Reply-To: <867gs9e6w3.fsf@ds4.des.no> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Arthur Mesh , freebsd-security@freebsd.org, "Simon L. B. Nielsen" , freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 23:00:26 -0000 On 09/04/2012 03:54 PM, Dag-Erling Smørgrav wrote: > Doug Barton writes: >> Yes, I know this, that's why I suggested it. :) > > Sorry, I thought you meant it should be discussed on freebsd-security as > opposed to freebsd-rc. well clearly you weren't alone in that assumption, so clearly I should have been more clear. :) Doug From owner-freebsd-security@FreeBSD.ORG Tue Sep 4 23:37:16 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 9FA4E106564A; Tue, 4 Sep 2012 23:37:16 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF1D8FC08; Tue, 4 Sep 2012 23:37:16 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 923116D5B; Wed, 5 Sep 2012 01:37:15 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 5D48682E2; Wed, 5 Sep 2012 01:37:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> Date: Wed, 05 Sep 2012 01:37:15 +0200 In-Reply-To: <5043DBAF.40506@FreeBSD.org> (Doug Barton's message of "Sun, 02 Sep 2012 15:20:31 -0700") Message-ID: <86y5kpcqc4.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - 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: Tue, 04 Sep 2012 23:37:16 -0000 (shameless thread hijacking) Speaking of rc.d and entropy, is the following code in /etc/rc.d/sshd really necessary? seeded=3D`sysctl -n kern.random.sys.seeded 2>/dev/null` if [ "x${seeded}" !=3D "x" ] && [ ${seeded} -eq 0 ] ; then warn "Setting entropy source to blocking mode." echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D" echo "Type a full screenful of random junk to unblock" echo "it and remember to finish with . This will" echo "timeout in ${timeout} seconds, but waiting for" echo "the timeout without typing junk may make the" echo "entropy source deliver predictable output." echo "" echo "Just hit for fast+insecure startup." echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D" sysctl kern.random.sys.seeded=3D0 2>/dev/null read -t ${timeout} junk echo "${junk}" `sysctl -a` `date` > /dev/random fi Considering, among other factors, how late in the boot sshd actually starts, and how much disk and / or network activity has occurred by that point. I don't believe this was how it was initially supposed to work, by the way. The original code *intentionally* always blocked, but it was slightly obfuscated. Two years after it was written, someone who misunderstood it submitted a PR, and several other someones who didn't understand it either came up with an incorrect fix and committed it. Neither Mark, who wrote the original code, nor I, who was (and still am) the OpenSSH maintainer, were consulted. BTW, it might be a good idea to run "/etc/rc.d/sshd keygen" from the installer if sshd is enabled during installation. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 01:12:58 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906A8106566C for ; Wed, 5 Sep 2012 01:12:58 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D8DA98FC14 for ; Wed, 5 Sep 2012 01:12:57 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so5596395wgb.31 for ; Tue, 04 Sep 2012 18:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=inP/GwrTGCWex9ZMA4QOsh8+46iYFNxQnjYCZcGpLas=; b=Cr7hUcV1NsNIquI4jkLUfBS0IlGE0Vpj588EMin1y0I7DpIFZKwlwGLpMOw9n8zvLU RsPKpJDc28GjWMVaEzhe8vhuRZcRfCk0J2EH6rB82i9aVYwtMDjW4XiHAVh97vZDtLX5 DHilp2nJy0+1hbGCm7RErnWK7Q8ijtyVCW+oeGuiplyheNdTDfZlMj5c267YyXjQIcNk OoruEzkNe2KSjTOQ1aSuH5SZiiTy3/lVuDaUh2MHHvpQIlsE6rI7ioMRKcAMzxOu/PlX TltcCwIS1nUhvVej9iaHxD5u0I76OAUDPuYfLRthjReUhJkjk3MweTnPSF4PqG7bc49r dHBQ== Received: by 10.216.241.200 with SMTP id g50mr12206761wer.79.1346807571153; Tue, 04 Sep 2012 18:12:51 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id t8sm26700517wiy.3.2012.09.04.18.12.49 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 18:12:50 -0700 (PDT) Date: Wed, 5 Sep 2012 02:12:48 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120905021248.5a17ace9@gumby.homeunix.com> In-Reply-To: <50468326.8070009@FreeBSD.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Wed, 05 Sep 2012 01:12:58 -0000 On Tue, 04 Sep 2012 15:39:34 -0700 Doug Barton wrote: > and given what Yarrow does to > obfuscate the internal entropy state I'm not confident that hashing > the input is either necessary or desirable. All of the low-grade entropy should go through sha256. Anything written into /dev/random is passed by random_yarrow_write() 16 Bytes at time into random_harvest_internal() which copies it into a buffer and queues it up. If there are 256 buffers queued random_harvest_internal() simply returns without doing anything. The yarrow kernel thread moves all of the entropy queues into a local queue, processes that queue and then pauses for 100ms and loops. That means that each time around the loop only a maximum of 4096 bytes can be processed. Anything after that is discarded. It seems very likely that /entropy is completely discarded most of the time, which means that the first 4096 bytes of " ps -fauxww ; sysctl -a" is the only entropy that makes it through to yarrow, and that's practically nothing. On a sufficiently fast system the entropy buffers may still be saturated when rc.d/random runs, so in theory they could be lost too. And embedded doesn't necessarily imply slow. I'm not overly concerned about this because anything that doesn't generate enough entropy naturally, increasingly tends to have a hardware generator, but it's easy to fix it, so it should be fixed. From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 04:41:20 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E7886106566B for ; Wed, 5 Sep 2012 04:41:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C09B814DAC5; Wed, 5 Sep 2012 04:41:20 +0000 (UTC) Message-ID: <5046D7F0.1000601@FreeBSD.org> Date: Tue, 04 Sep 2012 21:41:20 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: RW References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120905021248.5a17ace9@gumby.homeunix.com> In-Reply-To: <20120905021248.5a17ace9@gumby.homeunix.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Wed, 05 Sep 2012 04:41:21 -0000 Can you point out where in the source you're seeing these things? Thanks, Doug On 09/04/2012 06:12 PM, RW wrote: > On Tue, 04 Sep 2012 15:39:34 -0700 > Doug Barton wrote: > >> and given what Yarrow does to >> obfuscate the internal entropy state I'm not confident that hashing >> the input is either necessary or desirable. > > All of the low-grade entropy should go through sha256. > > Anything written into /dev/random is passed by random_yarrow_write() 16 > Bytes at time into random_harvest_internal() which copies it into a > buffer and queues it up. If there are 256 buffers queued > random_harvest_internal() simply returns without doing anything. > > The yarrow kernel thread moves all of the entropy queues into a local > queue, processes that queue and then pauses for 100ms and loops. That > means that each time around the loop only a maximum of 4096 bytes can > be processed. Anything after that is discarded. > > It seems very likely that /entropy is completely discarded most of the > time, which means that the first 4096 bytes of " ps -fauxww ; sysctl -a" > is the only entropy that makes it through to yarrow, and that's > practically nothing. > > On a sufficiently fast system the entropy buffers may still be saturated > when rc.d/random runs, so in theory they could be lost too. And embedded > doesn't necessarily imply slow. > > I'm not overly concerned about this because anything that doesn't > generate enough entropy naturally, increasingly tends to have a hardware > generator, but it's easy to fix it, so it should be fixed. > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 12:47:29 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E2B71065670 for ; Wed, 5 Sep 2012 12:47:29 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBCB08FC14 for ; Wed, 5 Sep 2012 12:47:28 +0000 (UTC) Received: by eaak11 with SMTP id k11so189431eaa.13 for ; Wed, 05 Sep 2012 05:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=QZIdVNv7b2RtpPyH7rVlryicXBtTYcA8MZxWuGiuk8s=; b=sZk1yC6u/jTCteWIvwGQbo1zKf/RqwH5wxIeoZI0qoEiN7FENAS568OV9pfJGz64LY RruuAA39Vyo2p4Rax/yGT17OTa+c3XCYxwVHUywSu5aoA1sub1SftnKBrpqy87y0xioF FFu5Bj/gEVp+93VsNzpB4dImyMbhRI4NUT4SZjh29Arw9inaGKDqyNbw7MCpKld5d5pv sKVNJTcMJiO3kwCNtiQHIsyUiPqrotDgDCnIDPrggvmaol6p4HQRa1nQv1vWbjudTAnV FOZCnxdz3bjQlZFwJlIOVvWrMAquRGsBL16EnU9s0CDICWm2kKUwoAcLnHlZb7L+aapg kfxA== Received: by 10.14.3.66 with SMTP id 42mr16351196eeg.28.1346849242511; Wed, 05 Sep 2012 05:47:22 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id z3sm3940222eel.15.2012.09.05.05.47.08 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 05:47:21 -0700 (PDT) Date: Wed, 5 Sep 2012 13:47:07 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120905134707.09a71c18@gumby.homeunix.com> In-Reply-To: <5046D7F0.1000601@FreeBSD.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120905021248.5a17ace9@gumby.homeunix.com> <5046D7F0.1000601@FreeBSD.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Wed, 05 Sep 2012 12:47:29 -0000 On Tue, 04 Sep 2012 21:41:20 -0700 Doug Barton wrote: > Can you point out where in the source you're seeing these things? It's in src/sys/dev/random/randomdev_soft.c: random_yarrow_write() random_harvest_internal() random_kthread() ------------------------------------------------------------------ void random_yarrow_write(void *buf, int count) { int i; u_int chunk; /* * Break the input up into HARVESTSIZE chunks. The writer has too * much control here, so "estimate" the entropy as zero. */ for (i = 0; i < count; i += HARVESTSIZE) { chunk = HARVESTSIZE; if (i + chunk >= count) chunk = (u_int)(count - i); random_harvest_internal(get_cyclecount(), (char *)buf + i, chunk, 0, 0, RANDOM_WRITE); } } /* Entropy harvesting routine. This is supposed to be fast; do * not do anything slow in here! */ static void random_harvest_internal(u_int64_t somecounter, const void *entropy, u_int count, u_int bits, u_int frac, enum esource origin) { struct harvest *event; KASSERT(origin == RANDOM_START || origin == RANDOM_WRITE || origin == RANDOM_KEYBOARD || origin == RANDOM_MOUSE || origin == RANDOM_NET || origin == RANDOM_INTERRUPT || origin == RANDOM_PURE, ("random_harvest_internal: origin %d invalid\n", origin)); /* Lockless read to avoid lock operations if fifo is full. */ if (harvestfifo[origin].count >= RANDOM_FIFO_MAX) return; mtx_lock_spin(&harvest_mtx); /* * Don't make the harvest queues too big - help to prevent low-grade * entropy swamping */ if (harvestfifo[origin].count < RANDOM_FIFO_MAX) { event = STAILQ_FIRST(&emptyfifo.head); if (event != NULL) { /* Add the harvested data to the fifo */ STAILQ_REMOVE_HEAD(&emptyfifo.head, next); harvestfifo[origin].count++; event->somecounter = somecounter; event->size = count; event->bits = bits; event->frac = frac; event->source = origin; /* XXXX Come back and make this dynamic! */ count = MIN(count, HARVESTSIZE); memcpy(event->entropy, entropy, count); STAILQ_INSERT_TAIL(&harvestfifo[origin].head, event, next); } } mtx_unlock_spin(&harvest_mtx); } static void random_kthread(void *arg __unused) { STAILQ_HEAD(, harvest) local_queue; struct harvest *event = NULL; int local_count; enum esource source; STAILQ_INIT(&local_queue); local_count = 0; /* Process until told to stop */ for (; random_kthread_control >= 0;) { /* Cycle through all the entropy sources */ mtx_lock_spin(&harvest_mtx); for (source = RANDOM_START; source < ENTROPYSOURCE; source++) { /* * Drain entropy source records into a thread-local * queue for processing while not holding the mutex. */ STAILQ_CONCAT(&local_queue, &harvestfifo[source].head); local_count += harvestfifo[source].count; harvestfifo[source].count = 0; } /* * Deal with events, if any, dropping the mutex as we process * each event. Then push the events back into the empty * fifo. */ if (!STAILQ_EMPTY(&local_queue)) { mtx_unlock_spin(&harvest_mtx); STAILQ_FOREACH(event, &local_queue, next) random_process_event(event); mtx_lock_spin(&harvest_mtx); STAILQ_CONCAT(&emptyfifo.head, &local_queue); emptyfifo.count += local_count; local_count = 0; } mtx_unlock_spin(&harvest_mtx); KASSERT(local_count == 0, ("random_kthread: local_count %d", local_count)); /* * If a queue flush was commanded, it has now happened, * and we can mark this by resetting the command. */ if (random_kthread_control == 1) random_kthread_control = 0; /* Work done, so don't belabour the issue */ pause("-", hz / 10); } random_set_wakeup_exit(&random_kthread_control); /* NOTREACHED */ } From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 13:55:02 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 53B1E10656F2; Wed, 5 Sep 2012 13:55:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9E68FC19; Wed, 5 Sep 2012 13:55:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50D4DB95E; Wed, 5 Sep 2012 09:55:01 -0400 (EDT) From: John Baldwin To: freebsd-security@freebsd.org Date: Wed, 5 Sep 2012 09:44:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201208222337.q7MNbORo017642@svn.freebsd.org> <20120905021248.5a17ace9@gumby.homeunix.com> <5046D7F0.1000601@FreeBSD.org> In-Reply-To: <5046D7F0.1000601@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209050944.38042.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Sep 2012 09:55:01 -0400 (EDT) Cc: RW , Doug Barton 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: Wed, 05 Sep 2012 13:55:02 -0000 On Wednesday, September 05, 2012 12:41:20 am Doug Barton wrote: > Can you point out where in the source you're seeing these things? He did. A write to /dev/random calls random_write() in randomdev.c. In the pure software case, the 'random_systat.write()' that is called in the loop in random_write() is random_yarrow_write() in randomdev_soft.c. That function calls random_harvest_interval() splits up the input data into chunks of HARVESTSIZE bytes (or less for the final bit of data). HARVESTSIZE is 16: void random_yarrow_write(void *buf, int count) { int i; u_int chunk; /* * Break the input up into HARVESTSIZE chunks. The writer has too * much control here, so "estimate" the entropy as zero. */ for (i = 0; i < count; i += HARVESTSIZE) { chunk = HARVESTSIZE; if (i + chunk >= count) chunk = (u_int)(count - i); random_harvest_internal(get_cyclecount(), (char *)buf + i, chunk, 0, 0, RANDOM_WRITE); } } random_harvest_interval() only accepts RANDOM_FIFO_MAX writes into a given FIFO: /* Entropy harvesting routine. This is supposed to be fast; do * not do anything slow in here! */ static void random_harvest_internal(u_int64_t somecounter, const void *entropy, u_int count, u_int bits, u_int frac, enum esource origin) { struct harvest *event; ... /* Lockless read to avoid lock operations if fifo is full. */ if (harvestfifo[origin].count >= RANDOM_FIFO_MAX) return; mtx_lock_spin(&harvest_mtx); /* * Don't make the harvest queues too big - help to prevent low-grade * entropy swamping */ if (harvestfifo[origin].count < RANDOM_FIFO_MAX) { ... } } RANDOM_FIFO_MAX is 256. This means that a big write(2) of data will only store up to 256 chunks of at most 16 bytes apiece (hence 256 * 16 = 4096). The rest would all be thrown away. You might be able to do more than that if the yarrow thread is running concurrently. However, given the work involved in draining the FIFO, I doubt it could drain the FIFO faster than the write(2) could queue data to it, so I don't expect you would be able to get much more than 4096 bytes used from the one big write into /dev/random. > Thanks, > > Doug > > On 09/04/2012 06:12 PM, RW wrote: > > On Tue, 04 Sep 2012 15:39:34 -0700 > > Doug Barton wrote: > > > >> and given what Yarrow does to > >> obfuscate the internal entropy state I'm not confident that hashing > >> the input is either necessary or desirable. > > > > All of the low-grade entropy should go through sha256. > > > > Anything written into /dev/random is passed by random_yarrow_write() 16 > > Bytes at time into random_harvest_internal() which copies it into a > > buffer and queues it up. If there are 256 buffers queued > > random_harvest_internal() simply returns without doing anything. > > > > The yarrow kernel thread moves all of the entropy queues into a local > > queue, processes that queue and then pauses for 100ms and loops. That > > means that each time around the loop only a maximum of 4096 bytes can > > be processed. Anything after that is discarded. > > > > It seems very likely that /entropy is completely discarded most of the > > time, which means that the first 4096 bytes of " ps -fauxww ; sysctl -a" > > is the only entropy that makes it through to yarrow, and that's > > practically nothing. > > > > On a sufficiently fast system the entropy buffers may still be saturated > > when rc.d/random runs, so in theory they could be lost too. And embedded > > doesn't necessarily imply slow. > > > > I'm not overly concerned about this because anything that doesn't > > generate enough entropy naturally, increasingly tends to have a hardware > > generator, but it's easy to fix it, so it should be fixed. > > > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to "freebsd-security- unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 20:32:23 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id 8CF011065680; Wed, 5 Sep 2012 20:32:23 +0000 (UTC) Date: Wed, 5 Sep 2012 13:32:22 -0700 From: David O'Brien To: Doug Barton Message-ID: <20120905203222.GA2920@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5043DBAF.40506@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:32:23 -0000 On Sun, Sep 02, 2012 at 03:20:31PM -0700, Doug Barton wrote: > On 08/22/2012 11:43, David E. O'Brien wrote: > > Author: obrien > > Date: Wed Aug 22 18:43:21 2012 > > New Revision: 239569 > > URL: http://svn.freebsd.org/changeset/base/239569 > > > > Log: > > Remove old entropy seeding after consumption initializing /dev/random PRNG. > > Not doing so opens us up to replay attacks. > > I object to this change, and would like to see it discussed more. > > When I did the original implementation of the entropy seeding scripts > this issue was discussed, and the decision not to remove the entropy > after seeding was deliberate. Hi Doug, I would like to refresh my memory of this discussion. Can you help me narrow down the date and mailing list such that I can go find it archives? It may help me understand your POV in this thread. I've read what I could find from Bruce Schneier on entropy seeding. It is my read that to not delete the seed input goes squarely against the yarrow inventor's recommendations. I tried to document this in the commit. Do you have access to Practical Cryptography, ISBN: 0-471-22357-3 by Niels Ferguson and Bruce Schneier that you could read 10.5 and 10.6 and give your thoughts? > There are 3 possibilities. First, the > system boots normally, gets seeded, and runs for a period of time longer > than ($entropy_save_cum x cron interval), which by default is 88 > minutes. In this case all of the entropy files will be replaced, so the > "postrandom" change will be spurious. I almost agree, but not quite. My read of /usr/libexec/save-entropy is that it does not overwrite ${entropy_file}. Only that /usr/libexec/save-entropy saves additional seeding material. Thus there is still a chance of replaying (reseeding with) ${entropy_file}. I'm curious, where did the default value of ${entropy_save_num} of "8" come from? Given we're talking about real machines and thus finite constraints in space, why stuff in 8 * 2k worth of seed all at the same time? What is the improvement in the pseudo randomness in /dev/random output after that much seeding? Why not 1/2 that value (4)? Or why not 9, to maximize the amount of seeding within a single digit extension? > In the second case, the system boots successfully, gets seeded, but runs > for less than the default 88 minutes. In that case there will be at > least (uptime / cron interval) new files, and the same number of old > files removed. So while some of the entropy will be "stale" at next > reboot, it won't all be the same, so even the stale entropy is better > than nothing in helping to reseed. It seems this is a point of contention. Arthur and I disagree. I believe you do not feel seeding with (uptime / cron interval) new [/dev/random generated] files is sufficient for a good pseudo random /dev/random. Is that correct? I believe you are questioning what is enough entropy seeding for obtaining a secure key? And that it entropy_save_num(=8) is required or strongly recommended. This is such a key question that Schneier even states this is probably the hardest problem to solve in PRNG design. The yarrow design has mechanisms it uses to answer this. It tracks the number of bits of entropy fed into it to decide for itself. > In the third case, the system boots, but is then rebooted again before > the cron interval has had a chance to replace even 1 file. This is the > case where removing the old entropy is particularly pathological. It > reduces the available seeding material without adding anything new. From > a security perspective, that's worse than the possibility of a replay > attack. How is it worse? /etc/rc.d/postrandom does add something new by generating a new ${entropy_file} during this time -- providing for 4k of good entropy seed. Less assume only a 10% entropy rate. That's still 409 bits of entropy -- which I claim is good enough to prime yarrow to operate securely. > For all 3 cases, it's important to keep in mind a few things. Primarily, > yarrow is designed to avoid exactly the kind of "replay" problem that > this change was intended to fix, so it's almost certainly at best > unnecessary. I am not sure what section of http://www.schneier.com/paper-yarrow.ps.gz are you referring to. I do not see "replay" explicitly stated. Please note that section 3.1 "How PRNGs are Compromised" in the paragraph titled "Mishandling of Keys and Seed Files" Schneier states: seed files are easy to mishandle in various ways, ..., or by opening a seed file, but failing to update it every time it is used. That statement is in agreement with everything else I've seen from Schneier on this subject. Also section 5.2 "Entropy Accumulator" in the "Security Arguments" paragraph: Consider the situation of an attacker trying to predict the whole sequence of inputs to be fed into the user's entropy accumulator. ... Ultimately, an attacker in this position cannot be resisted effectively by the design of the algorithm, ... > Of nearly equal importance it should be kept in mind that > we add a non-zero amount of unique material at every boot, so a true > replay attack isn't possible, even without this change. What is the non-zero amount of unique material we seed at every boot? Most of the 'better_than_nothing' output is guessable by a local non-root account. The best thing saving us when the seed inputs are known, is the stirring in of the CPU cycle counter. > In short, this change is at best unnecessary, and possibly detrimental. I do not see how it is either of those. Please explain further. -- -- David (obrien@FreeBSD.org) Obligatory amusement: http://www.chmil.org/bruce-facts-all.txt It was based on the Schneier Axiom, which reads: "Bruce Schneier said so." From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 20:40:51 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id A77161065678; Wed, 5 Sep 2012 20:40:51 +0000 (UTC) Date: Wed, 5 Sep 2012 13:40:50 -0700 From: David O'Brien To: Ian Lepore Message-ID: <20120905204050.GB820@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1346789717.1140.675.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:40:51 -0000 On Tue, Sep 04, 2012 at 02:15:17PM -0600, Ian Lepore wrote: > pscmd="ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl" I do like the changes that this gives over 'ps -fauxww'. root 11 80.6 0.0 0 32 - RL 8:40AM 0:03.09 [idle] - 1078 1495 0:03.09 8 8 root 11 42.8 0.0 0 32 - RL 8:40AM 0:04.23 [idle] - 1401 1012 0:04.23 8 8 root 5 21.6 0.0 0 16 - DL 8:40AM 0:02.17 [xpt_thrd] ffffffff811931e0 104 1 0:02.17 8 4 -vs- root 11 121.9 0.0 0 32 - RL 8:40AM 0:06.48 [idle] root 5 21.6 0.0 0 16 - DL 8:40AM 0:00.00 [xpt_thrd] > The sysctl -a in the original initrandom sequence was part of the killer > for execution time. On a 180mhz arm chip that command alone takes like > 3 seconds, and it generates a lot of unchanging boilerplate text. I > remember picking a few select values that had a good chance of being > different from one run to the next. I've found that 'sysctl -a' can generate ~270K of output with very little of it differing between runs. I've checked the output across reboots at the point that 'initrandom' runs. I've found sysctl kern.cp_times kern.cp_time kern.geom kern.lastpid \ kern.timecounter kern.tty_nout kern.tty_nin vm vfs debug dev.cpu to concentrate the changes across reboots. However, I have not tested this on ARM or MIPS to ensure these MIB's exist. Just to double check, you're saying the 3 seconds was for 'sysctl -a > /dev/null' vs. feeding that amount of input into /dev/random? > Those commands still generated a fair amount of unchanging boilerplate > text, and it's mostly the numbers that change, so I fed all the output > through tr to strip out everything but the numbers. I would use "tr -Cd '0123456789xabcdef'" since many of the numbers are in hex, and would restrict to just the sysctl output. But otherwise I like this idea. Can you time some things on your ARM? 'sysctl -a' vs. my MIB list above? Also your shorter list? -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 20:59:36 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 0BB1A1065670; Wed, 5 Sep 2012 20:59:36 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 72EF88FC12; Wed, 5 Sep 2012 20:59:34 +0000 (UTC) Received: from aspire.rulingia.com (12.58.233.220.static.exetel.com.au [220.233.58.12]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q85KxSOU061428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Sep 2012 06:59:33 +1000 (EST) (envelope-from peter@rulingia.com) Received: from aspire.rulingia.com (localhost [127.0.0.1]) by aspire.rulingia.com (8.14.5/8.14.5) with ESMTP id q85KxKks010304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2012 06:59:20 +1000 (EST) (envelope-from peter@aspire.rulingia.com) Received: (from peter@localhost) by aspire.rulingia.com (8.14.5/8.14.5/Submit) id q85KxKfH010303; Thu, 6 Sep 2012 06:59:20 +1000 (EST) (envelope-from peter) Date: Thu, 6 Sep 2012 06:59:19 +1000 From: Peter Jeremy To: Doug Barton Message-ID: <20120905205919.GD2654@aspire.rulingia.com> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> <504687E1.3060203@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P+33d92oIH25kiaB" Content-Disposition: inline In-Reply-To: <504687E1.3060203@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, freebsd-rc@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: Wed, 05 Sep 2012 20:59:36 -0000 --P+33d92oIH25kiaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Sep-04 15:59:45 -0700, Doug Barton wrote: >I'm not sure I agree with that, since the combination of lower quality >input (the boilerplate) and higher quality (changing numbers) still >provides more bits to stir the pool with. Even though the average >quality is lower over the total number of bits I still think it's >probably more valuable to pump in the higher quantity given the internal >chewing that Yarrow does with the bits. I don't understand the point of feeding boilerplate into Yarrow. Yes, it will stir Yarrow's internal state but it does so in a predictable way so it doesn't add any entropy. On the downside, it doesn't appear to be possible to queue more than 4KB of input every 100msec - excess input is just discarded. This implies that feeding boilerplate into /dev/random just increases the probability that real entropy will be discarded. --=20 Peter Jeremy --P+33d92oIH25kiaB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBHvScACgkQ/opHv/APuIeYAgCgkpswJECvg09j61VhF5I/xqjb IYwAn1/NGKekUCoF9/YkelwcLZDWDDNE =r7Cu -----END PGP SIGNATURE----- --P+33d92oIH25kiaB-- From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 21:27:49 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 76B0E106564A for ; Wed, 5 Sep 2012 21:27:49 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id DF33B8FC1A for ; Wed, 5 Sep 2012 21:27:48 +0000 (UTC) Received: from aspire.rulingia.com (12.58.233.220.static.exetel.com.au [220.233.58.12]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q85LRhCX061611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Sep 2012 07:27:47 +1000 (EST) (envelope-from peter@rulingia.com) Received: from aspire.rulingia.com (localhost [127.0.0.1]) by aspire.rulingia.com (8.14.5/8.14.5) with ESMTP id q85LRZ8V010384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 07:27:35 +1000 (EST) (envelope-from peter@aspire.rulingia.com) Received: (from peter@localhost) by aspire.rulingia.com (8.14.5/8.14.5/Submit) id q85LRZkL010383 for freebsd-security@freebsd.org; Thu, 6 Sep 2012 07:27:35 +1000 (EST) (envelope-from peter) Date: Thu, 6 Sep 2012 07:27:34 +1000 From: Peter Jeremy To: freebsd-security@freebsd.org Message-ID: <20120905212734.GE2654@aspire.rulingia.com> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120905021248.5a17ace9@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ep0oHQY+/Gbo/zt0" Content-Disposition: inline In-Reply-To: <20120905021248.5a17ace9@gumby.homeunix.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 05 Sep 2012 21:27:49 -0000 --ep0oHQY+/Gbo/zt0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Sep-05 02:12:48 +0100, RW wrote: >All of the low-grade entropy should go through sha256. Overall, I like the idea of feeding the high-volume mixed quality "entropy" through SHA-256 or similar. >Anything written into /dev/random is passed by random_yarrow_write() 16 >Bytes at time into random_harvest_internal() which copies it into a >buffer and queues it up. If there are 256 buffers queued >random_harvest_internal() simply returns without doing anything.=20 This would seem to open up a denial-of-entropy attack on random(4): All entropy sources feed into Yarrow via random_harvest_internal() which queues the input into a single queue - harvestfifo. When this queue is full, further input is discarded. If I run "dd if=3D/dev/zero of=3D/dev/random" then harvestfifo will be kept full of NULs, resulting in other entropy events (particularly from within the kernel) being discarded. There would still be a small amount of entropy from the get_cyclecount() calls but this is minimal. Is it worth splitting harvestfifo into multiple queues to prevent this? At least a separate queue for RANDOM_WRITE and potentially separate queues for each entropy source. --=20 Peter Jeremy --ep0oHQY+/Gbo/zt0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBHw8YACgkQ/opHv/APuIfkrwCgkZum7Lyrep1wQthkNAU44/ea IhMAnRrxd4u1x9//YZrmfkyx/s+Kqv58 =9EFJ -----END PGP SIGNATURE----- --ep0oHQY+/Gbo/zt0-- From owner-freebsd-security@FreeBSD.ORG Wed Sep 5 22:20:13 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id C637E106564A; Wed, 5 Sep 2012 22:20:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 4C6371511DA; Wed, 5 Sep 2012 22:20:13 +0000 (UTC) Message-ID: <5047D01D.5000802@FreeBSD.org> Date: Wed, 05 Sep 2012 15:20:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: obrien@freebsd.org References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120905203222.GA2920@dragon.NUXI.org> In-Reply-To: <20120905203222.GA2920@dragon.NUXI.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - 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: Wed, 05 Sep 2012 22:20:14 -0000 On 09/05/2012 13:32, David O'Brien wrote: > On Sun, Sep 02, 2012 at 03:20:31PM -0700, Doug Barton wrote: >> On 08/22/2012 11:43, David E. O'Brien wrote: >>> Author: obrien >>> Date: Wed Aug 22 18:43:21 2012 >>> New Revision: 239569 >>> URL: http://svn.freebsd.org/changeset/base/239569 >>> >>> Log: >>> Remove old entropy seeding after consumption initializing /dev/random PRNG. >>> Not doing so opens us up to replay attacks. >> >> I object to this change, and would like to see it discussed more. >> >> When I did the original implementation of the entropy seeding scripts >> this issue was discussed, and the decision not to remove the entropy >> after seeding was deliberate. > > Hi Doug, > I would like to refresh my memory of this discussion. Can you help > me narrow down the date and mailing list such that I can go find it > archives? It may help me understand your POV in this thread. I've explained my perspective as well as I can already. This has probably occurred to you, but searching the archives during the months prior to first commit for libexec/save-entropy is a good start. -security, -arch, -current ... maybe -hackers. Beyond that I really can't help, it was 12 years ago after all. :) > I've read what I could find from Bruce Schneier on entropy seeding. > It is my read that to not delete the seed input goes squarely against > the yarrow inventor's recommendations. I tried to document this in > the commit. Yes, I understand what you and Arthur are proposing. I also explained in detail in one of my replies to Arthur that I agree with this in principle, which is why the system that saves entropy files eventually replaces them all. My concern is for the case where the system is rebooted immediately after (as you propose) the old files are deleted. In that case, my understanding is that the combination of old entropy files and the new material that is added at each boot (both by the commands run in initrandom, and by hardware harvesting) is both better than not having the old entropy files available, AND not subject to replay attacks. You and Arthur are putting forward a theory that I'm wrong on both counts, without actually demonstrating the truth of your claims. If you think that the system as it existed before your changes is vulnerable, it would be nice to have that demonstrated. > Do you have access to Practical Cryptography, ISBN: 0-471-22357-3 by > Niels Ferguson and Bruce Schneier that you could read 10.5 and 10.6 > and give your thoughts? Not handy, no. My recollection is that not reusing static entropy files is a best case scenario, which is handled by my first example scenario (system runs longer than 88 minutes). >> There are 3 possibilities. First, the >> system boots normally, gets seeded, and runs for a period of time longer >> than ($entropy_save_num x cron interval), which by default is 88 >> minutes. In this case all of the entropy files will be replaced, so the >> "postrandom" change will be spurious. > > I almost agree, but not quite. My read of /usr/libexec/save-entropy > is that it does not overwrite ${entropy_file}. Of course not, that's handled by /etc/rc.d/random at shutdown time. As I've explained already, the 2 things are entirely separate in order to minimize the writes to the root file system. > Only that > /usr/libexec/save-entropy saves additional seeding material. > > Thus there is still a chance of replaying (reseeding with) > ${entropy_file}. If the system shuts down cleanly, $entropy_file will be a new one. One of the reasons for keeping the static files in /var/db/entropy is to account for the case of a fast reboot where the material in $entropy_file is of low quality because the device never got an adequate seed. > I'm curious, where did the default value of ${entropy_save_num} of "8" > come from? Given we're talking about real machines and thus finite > constraints in space, why stuff in 8 * 2k worth of seed all at the same > time? What is the improvement in the pseudo randomness in /dev/random > output after that much seeding? Why not 1/2 that value (4)? Or why not > 9, to maximize the amount of seeding within a single digit extension? The number 8 was chosen pseudo-randomly (pardon the pun) as a value that would certainly be "more than enough" without taking up too much of what might be precious space in /var. It was made a variable in order to allow for users who wanted more or needed less. If you'd like to do some rigorous testing and demonstrate that a different default is needed, I would be happy to see that. >> In the second case, the system boots successfully, gets seeded, but runs >> for less than the default 88 minutes. In that case there will be at >> least (uptime / cron interval) new files, and the same number of old >> files removed. So while some of the entropy will be "stale" at next >> reboot, it won't all be the same, so even the stale entropy is better >> than nothing in helping to reseed. > > It seems this is a point of contention. Arthur and I disagree. Yes, I understand that you disagree. :) > I believe you do not feel seeding with (uptime / cron interval) new > [/dev/random generated] files is sufficient for a good pseudo random > /dev/random. Is that correct? I believe you are questioning what is > enough entropy seeding for obtaining a secure key? And that it > entropy_save_num(=8) is required or strongly recommended. > > This is such a key question that Schneier even states this is probably > the hardest problem to solve in PRNG design. Yup. That much I do remember very clearly, and I clearly remember that the decision was made to try to compensate for all possible weaknesses of a real world system, vs. a theoretically perfect one. That's why we replace the files as soon as is practical, but keep the ones we haven't had a chance to replace yet. > The yarrow design has > mechanisms it uses to answer this. It tracks the number of bits of > entropy fed into it to decide for itself. Yup. :) >> In the third case, the system boots, but is then rebooted again before >> the cron interval has had a chance to replace even 1 file. This is the >> case where removing the old entropy is particularly pathological. It >> reduces the available seeding material without adding anything new. From >> a security perspective, that's worse than the possibility of a replay >> attack. > > How is it worse? /etc/rc.d/postrandom does add something new by > generating a new ${entropy_file} during this time -- providing for 4k > of good entropy seed. Less assume only a 10% entropy rate. That's > still 409 bits of entropy -- which I claim is good enough to prime > yarrow to operate securely. And what I'd like to see is some proof of that claim. >> For all 3 cases, it's important to keep in mind a few things. Primarily, >> yarrow is designed to avoid exactly the kind of "replay" problem that >> this change was intended to fix, so it's almost certainly at best >> unnecessary. > > I am not sure what section of http://www.schneier.com/paper-yarrow.ps.gz > are you referring to. I do not see "replay" explicitly stated. I'm referring to the way that Yarrow uses entropy internally which is (in part) designed to help prevent exactly the kind of replay attack you're referring to. > Please note that section 3.1 "How PRNGs are Compromised" in the > paragraph titled "Mishandling of Keys and Seed Files" Schneier states: > > seed files are easy to mishandle in various ways, ..., or by > opening a seed file, but failing to update it every time it is used. First, this paragraph is talking about systems that are not Yarrow. Second (and once again) this is talking about a theoretical perfect system. The word "reboot" doesn't appear in the paper either. :) > That statement is in agreement with everything else I've seen from > Schneier on this subject. > > Also section 5.2 "Entropy Accumulator" in the "Security Arguments" > paragraph: > > Consider the situation of an attacker trying to predict the whole > sequence of inputs to be fed into the user's entropy accumulator. > ... > Ultimately, an attacker in this position cannot be resisted > effectively by the design of the algorithm, ... So once again, you have to take into account the _whole_ sequence of inputs. By default, /dev/random starts hardware seeding the moment it is loaded. The commands in initrandom also provide _some_ (albeit in a non-trivial number of cases not much) entropy. And you conveniently cut out the bit from that paper about how difficult the attacker's job is even if they can predict every byte of input. :) However, this does give me another idea about how we can improve the system. rc.d/random currently slurps the files in numerical order. We could use some bit of the data that is generated at boot time to pluck out a "random" value for the starting point. That would make the attacker's job harder, even with perfect knowledge of what the inputs are. >> Of nearly equal importance it should be kept in mind that >> we add a non-zero amount of unique material at every boot, so a true >> replay attack isn't possible, even without this change. > > What is the non-zero amount of unique material we seed at every boot? See above. > Most of the 'better_than_nothing' output is guessable by a local non-root > account. And how are they going to be logged in at boot time? I also think you're rather dramatically underestimating the increase in difficulty of guessing the interior state that even a small change in the inputs (hardware as well as initrandom) provides. Please note that this is a different issue from the overall quality of the entropy available to the device at, or shortly after boot time. > The best thing saving us when the seed inputs are known, is the > stirring in of the CPU cycle counter. Yes, that's one of the factors that I believe helps refute your claim that reusing the seed files after a short uptime makes is vulnerable to replay attacks. >> In short, this change is at best unnecessary, and possibly detrimental. > > I do not see how it is either of those. Please explain further. I have now explained the same points repeatedly to both you and Arthur. IMO, neither of you has chosen to thoroughly address the issues I've raised, instead the same assertions have been repeated. I've asked repeatedly for you(pl.) to demonstrate the truth of your claims, and given that you(pl.) are the ones proposing a fairly dramatic change to a security system that has served for almost 12 years, I think that the burden of proof is on you. Further, prior to this message I made one concrete proposal that I think helps address your concerns, writing a new entropy file to /var/db/entropy at boot time. I have yet to hear either of you respond to that. I'm also making another proposal above, "randomizing" the start point in the list of files from /var/db/entropy, which I think unarguably strengthens the overall system, even if only a little. I also think that it helps to address your concerns about replay, so I'm interested in your thoughts on that issue as well. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 01:09:40 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12BA1106564A for ; Thu, 6 Sep 2012 01:09:40 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 160468FC0C for ; Thu, 6 Sep 2012 01:09:38 +0000 (UTC) Received: by weyx56 with SMTP id x56so951799wey.13 for ; Wed, 05 Sep 2012 18:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=gPOBU3WBCyoJvP6EbKAwSmMRCrklFqeEN+gzOBA5pf4=; b=nnCTFLC88PoFUAWE9zLTlBFmKyFO8W5tEv2puXdD990wGd+Nk6YfZm82VX5MS+Ia3J mjh3FlFkmywrO3T2OQsojDjisCZvRXLeWf9iVs+t8sje/bGjrf6/f67gLIzem/P6W/zN s8lN3GCu7Vmtb6j33rsbsPNatWT31olMGY2ilTJmu8WaLtquY7LQRFAOoJksRttjkfTE c5pGIafUlzdj9+UUVjnZ9a6EWcj7OXyzW8yxlJznGZ5zN9r+FF54IAurDgyVrsa5XD8n Fl5y+qvKQUhR/vGoqg0VS5hwJM3FTbsy6Dykjk/BOES8LodGTSsvsMtVK2hyITerZCrh vpmQ== Received: by 10.216.131.22 with SMTP id l22mr209883wei.96.1346893777520; Wed, 05 Sep 2012 18:09:37 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id fr4sm1696523wib.8.2012.09.05.18.09.35 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 18:09:36 -0700 (PDT) Date: Thu, 6 Sep 2012 02:09:34 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120906020934.2b97681d@gumby.homeunix.com> In-Reply-To: <20120905212734.GE2654@aspire.rulingia.com> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120905021248.5a17ace9@gumby.homeunix.com> <20120905212734.GE2654@aspire.rulingia.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Thu, 06 Sep 2012 01:09:40 -0000 On Thu, 6 Sep 2012 07:27:34 +1000 Peter Jeremy wrote: > Is it worth splitting harvestfifo into multiple queues to prevent > this? At least a separate queue for RANDOM_WRITE and potentially > separate queues for each entropy source. It already does that. That's what the index "origin" is for. From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 14:28:17 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id D662A106566C; Thu, 6 Sep 2012 14:28:17 +0000 (UTC) Date: Thu, 6 Sep 2012 07:28:16 -0700 From: David O'Brien To: Doug Barton Message-ID: <20120906142816.GA13179@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50453686.9090100@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:28:18 -0000 On Mon, Sep 03, 2012 at 04:00:22PM -0700, Doug Barton wrote: > On 09/03/2012 14:46, Arthur Mesh wrote: > > On Mon, Sep 03, 2012 at 02:13:18PM -0700, Doug Barton wrote: > >>> Yes, except /entropy is generated after /var/db/entropy/* and old > >>> /entropy was fed in to yarrow. So I don't believe saying it's poorly > >>> seeded at that point is fair. I agree with Arthur here. > The static files are provided as a means to stir the pool to unblock the > device at boot time. Actually we haven't blocked since 2004. See the ".seeded = 1" initialization to 'struct random_systat random_yarrow' in sys/dev/random/randomdev_soft.c Per r132346: Start the entropy device insecure/unblocked. I'll be handing over responsibility for critical randomness requirements (like sshd) to rc.d/* Since then, the static files are a means to seed /dev/random to have it operating securely ASAP. We do not document or take into much consideration which binaries run in /etc/rc.d/* use /dev/random. Who knows? Should the system be so aware of /dev/random's consumption? Or is it better to get yarrow to steady-state ASAP? Have you booted a machine with: Index: harvest.c =================================================================== --- harvest.c (revision 237320) +++ harvest.c (working copy) @@ -51 +51 @@ static int read_random_phony(void *, int -struct harvest_select harvest = { 1, 1, 1, 0 }; +struct harvest_select harvest = { 0, 0, 0, 0 }; and these /etc/rc.conf lines: entropy_file="NO" entropy_dir="NO" entropy_save_sz="0" entropy_save_num="0" harvest_interrupt="NO" harvest_ethernet="NO" harvest_p_to_p="NO" I had no blocking during boot. My sysctl output (the last line I added to verify I had no entropy processed): kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 0 kern.random.sys.harvest.point_to_point: 0 kern.random.sys.harvest.interrupt: 0 kern.random.sys.harvest.swi: 0 kern.random.sys.harvest.entropy_processed: write=0/0, keyboard=0/0, mouse=0/0, net=0/0, interrupt=0/0, pure=0/0 > But it is "better" (for sufficiently paranoid > definitions of "better") to wait as long as possible after boot before > actually utilizing the device for something important (like creating a > new seed). Please state a reference for this conclusion. Are you basing your POV on common sense? From something in yarrow paper? From some knowledge of /dev/random producing output with poor entropy? The yarrow paper speaks of it being "preferable to have what ever extra entropy there is in the PRNG's key". But that doesn't mean wait forever. What do you feel is the minimal amount of pooled up entropy one should have for /dev/random to give high quality randomness? This is also why I changed the order of the seed inputs in 'initrandom'. In our implementation, writes to /dev/random are handled as any good device driver should. The input is buffered, and then an asynchronous kernel thread is schedule to process the input. So the seed is not worked into the system at the point the write(2) returns. Thus I put our best entropy input ahead of our lesser one to do what I could to reduce the time until /dev/random's outputs are "secure". > Ummm ... I think you have the logic backwards on this. :) We have a > system, designed with fairly thorough knowledge of how Yarrow works, and > taking all possible scenarios into account. It's stood the test of time > for many years now. Has it? Have you done an analysis of its operation? A recent code review? A cryptographic analysis of /dev/random's output vs. input? I'm quoting the Yarrow paper and later Fortuna PRNG as documented in Practical Cryptography. Have you seen the /* 7. Dump to seed file */ /* XXX Not done here yet */ comments in sys/dev/random/yarrow.c:reseed()? Are you saying one cannot improve upon our implementation? For instance, best as I can tell we have not fully implemented the Yarrow design. The design depends on a specialized statistical estimator that is used to detect abnormal situations in which the samples have a very low entropy. > > Also, please consider the fact that Schneier explicitly recommends > > against reusing same entropy seed files... > > Yeah, I've covered that. I'm sorry I missed that. Could you state it again as I couldn't find where you addressed not reusing seed input. > What if, instead of replacing /entropy, we add an additional file in > /var/db/entropy at boot time that is numerically 1 higher than > $entropy_save_num ? (Note, I have to fix the rotation script to account > for this, but I have had "improve the rotation script" on my TODO list > for a long time now, and this is a good excuse for me to get a round > 'tuit.) That way should the reboot happen before the default 11 minutes > that kicks in the cron job we still have fresh entropy to reseed with, > and we're not losing anything that we had already. When the rotation > script runs it will delete the (IMO) low quality file created at boot, > and saved-entropy.1 will be a fresh, clean file with (again, arguably) > higher quality entropy that will be used at the next boot time. I really don't see the need for this much additional complication. > I briefly considered a different solution like appending to /entropy > instead of replacing it, That still leaves a replay of the part you're proposing to append to. > but one of the reasons I'm queasy about > touching that file at boot time is that in the event that the system > crashes shortly after boot (which happens to those of us who track > -current rather often) I don't want the / file system to have been > written to. I don't have that that kind of trouble with -CURRENT in a long time. Even if we did, I don't think we should be optimizing for -CURRENT. If that is what you're wanting to optimize, then why aren't you proposing a change to /etc/rc.d/FILESYSTEMS to push it farther down the 'rcorder /etc/rc.d/*' ordered list? 'FILESYSTEMS' exists to say basic file systems are mounted and fully usable. If / shouldn't be writable then make a change to keep it R/O longer. Once a file system is mounted R/W, it is dirty if not cleanly unmounted. What is not writing to / solve? It is still dirty if one crashes. Is there a SU or SU+J specific bug you're thinking about? Note that some (many?) of us have a large / containing /usr and /var due to the new FreeBSD (and PC-BSD) installer, or following what Solaris and Irix did on workstations. In these cases our / is getting written to pretty early in boot. Even with a / that does not contain /usr or /var, what is the time delta you're saving? Amd will write to / when one logs in with NFS mounted home dirs. Should we add a 10 minute delay before allowing any non-root login so that we don't write to / shortly after boot? Opps, tcsh will write a history file to /, so we should also change root's shell to /bin/sh. There me be some other /etc/rc.d/ script that writes to / -- should we add a mechanism to push that to the end of the 'rcorder' ordering? > Having the /entropy file written out at shutdown time is a > "necessary evil" given that we can't be sure that /var is available in > the early stages of rc, Again, I don't understand your issue with writes to /. It isn't a R/O file system. I would understand saying '/entropy' is ugly and clutter in /. That's why on the system I'm writing this on I have it in /var (since /var is part of my /). > What do you think about the idea of adding a new file in /var/db/entropy? I don't believe I see a use in that. Please lists its qualities. How is it generated? Is it regenerated and if so when and how? What is its lifetime? When will it be used? -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 15:39:42 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F731065749; Thu, 6 Sep 2012 15:39:42 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 389EC8FC20; Thu, 6 Sep 2012 15:39:35 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q86FdSkk000924; Thu, 6 Sep 2012 09:39:35 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q86FdOsD043870; Thu, 6 Sep 2012 09:39:24 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: obrien@FreeBSD.ORG In-Reply-To: <20120905204050.GB820@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> <20120905204050.GB820@dragon.NUXI.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Sep 2012 09:39:24 -0600 Message-ID: <1346945964.59094.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Sep 2012 16:17:18 +0000 Cc: Arthur Mesh , freebsd-security@FreeBSD.ORG, Doug Barton , freebsd-rc@FreeBSD.ORG, Mark Murray 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: Thu, 06 Sep 2012 15:39:42 -0000 On Wed, 2012-09-05 at 13:40 -0700, David O'Brien wrote: > On Tue, Sep 04, 2012 at 02:15:17PM -0600, Ian Lepore wrote: > > pscmd="ps -fauxrH -o nwchan,nivcsw,nvcsw,time,re,sl" > > I do like the changes that this gives over 'ps -fauxww'. > > root 11 80.6 0.0 0 32 - RL 8:40AM 0:03.09 [idle] - 1078 1495 0:03.09 8 8 > root 11 42.8 0.0 0 32 - RL 8:40AM 0:04.23 [idle] - 1401 1012 0:04.23 8 8 > root 5 21.6 0.0 0 16 - DL 8:40AM 0:02.17 [xpt_thrd] ffffffff811931e0 104 1 0:02.17 8 4 > > -vs- > root 11 121.9 0.0 0 32 - RL 8:40AM 0:06.48 [idle] > root 5 21.6 0.0 0 16 - DL 8:40AM 0:00.00 [xpt_thrd] > Yes, and a significant point is that the extra numbers at the end of each line tend to be different from one boot to the next on the same unit. That can be significant for an embedded system with no writable storage. There is no saved entropy, there is nothing unique about one unit compared to another in terms of looking at its configuration (dmesg, sysctl -a, whatever). On a system like that you've got to root out the little bit of real-world entropy available -- things like oscillators whose frequency varies with temperature just enough to change the timing of something by a few nanoseconds from one boot sequence to the next. From that, if you're lucky, you get a bit of butterfly effect that causes the processes listed by ps to appear in a different order because this time one of them got a few more cycles before an interrupt caused the scheduler to switch to some other process, and the process stats will be a little different as well. > > > The sysctl -a in the original initrandom sequence was part of the killer > > for execution time. On a 180mhz arm chip that command alone takes like > > 3 seconds, and it generates a lot of unchanging boilerplate text. I > > remember picking a few select values that had a good chance of being > > different from one run to the next. > > I've found that 'sysctl -a' can generate ~270K of output with very little > of it differing between runs. I've checked the output across reboots at > the point that 'initrandom' runs. > > I've found > sysctl kern.cp_times kern.cp_time kern.geom kern.lastpid \ > kern.timecounter kern.tty_nout kern.tty_nin vm vfs debug dev.cpu > to concentrate the changes across reboots. However, I have not tested > this on ARM or MIPS to ensure these MIB's exist. > > Just to double check, you're saying the 3 seconds was for > 'sysctl -a > /dev/null' vs. feeding that amount of input into > /dev/random? > Yeah, it was just the time to generate the output and feed it to /dev/null -- the zillion syscalls and all the text formatting eat up the time. I don't have one of those super-low-end systems available for testing right now, but a similar system (bit faster cpu and memory) is showing a fairly repeatable 0.80s for sysctl -a >/dev/null, and 0.30s for the oids you listed above. Of those oids you listed above, the vm and vfs generate a lot of text but it's mostly the vm.stats part that changes. The kern.geom output is pretty static on a given system, and oddly it takes a long time to generate compared to other oids. The cp_time is already included in cp_times. The dev.cpu is intel-specific. 0.30s - Your list above 0.18s - Your list minus kern.cp_time and vfs, changing vm to vm.stats 0.05s - Also remove kern.geom I wasn't super-formal with timing, it was just "time sysctl ...>/dev/null" run by hand several times to ensure that the numbers weren't varying by more than .02 or so from one run to the next. So, to reiterate, this is the set of oids that takes only .05s: kern.cp_times kern.lastpid kern.timecounter kern.tty_nout kern.tty_nin vm.stats > > > Those commands still generated a fair amount of unchanging boilerplate > > text, and it's mostly the numbers that change, so I fed all the output > > through tr to strip out everything but the numbers. > > I would use "tr -Cd '0123456789xabcdef'" since many of the numbers are > in hex, and would restrict to just the sysctl output. But otherwise I > like this idea. > My gut told me that feeding in just the parts that change the most and stripping out the boilerplate made sense, but in cryptography what seems like common sense isn't always correct. Given what Peter reported earlier about the /dev/random device discarding input if you feed it too much too fast, extracting 5-6K of changing numbers from the ~100K of boilerplate might have been a good idea. On the other hand, that also reduces the input character set to just 10-16 bytes, that's the kind of thing that makes me think "gut feelings" can be misleading. Oh, another point worth noting is that on ARM (and possibly MIPS) systems, forking and execing is particularly expensive (lots of virtual memory bookkeeping overhead), so part of what I was trying to do was run just 2 or 3 commands rather than 6-10 commands to generate the output. Changes to /bin/sh earlier this year to use vfork() have helped reduce the cost of running multiple commands. -- Ian From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 16:45:15 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id 847B810656D4; Thu, 6 Sep 2012 16:45:15 +0000 (UTC) Date: Thu, 6 Sep 2012 09:45:14 -0700 From: David O'Brien To: Doug Barton Message-ID: <20120906164514.GA14757@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50468326.8070009@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:45:15 -0000 On Tue, Sep 04, 2012 at 03:39:34PM -0700, Doug Barton wrote: > Regarding your changes in r240108: > > 1. Adding kenv to the mix is probably a good idea, however the output of > the ps command won't be the same both times it is run, which is why it > was in there twice. Doug, Have you actually looked at the 'ps' output from the two runs from within 'initrandom'? I have. On my test system I got 1608 bytes of output on 24 well structured lines. The two runs differed so little (only 5 lines) about all you could claim is might add 1 bit of entropy. But the search space to find the differences given the first run is so minimal I don't see that it adds any real value. You should be suggesting totally different commands to run that will provide better than a second run of 'ps'. > I'll have to give the kenv output a look. I would > also like to confirm that it's available on all platforms. Geez, I'm not that stupid. Do you see any guards within bin/Makefile that only build it for for some architectures? I verified we have it on MIPS, ARM, and PowerPC and gives some output. It does not give as much system-specific output as on x86 -- I wish it did, but the output can be rather unique on x86 it is worth including it. > 2. I'm not sure I like the change from cat'ing /bin/ls to the hash of > the kern.bootfile output. Given that most users stick with the GENERIC > kernel or the same custom kernel on multiple machines I'm not confident > that there will be a statistically significant difference in the amount > entropy between the 2, Vs /bin/ls? We have a chapter in the handbook on building your own kernel [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html]. Do we have a chapter on building a custom /bin/ls? A kernel build is a combination of 946 knobs. /bin/ls has 1, leading to two different results. So you really think there is more chance that /bin/ls will vary between two installations of the same version of FreeBSD? You don't believe most users use the same /bin/ls across multiple machines? > 3. Given that we're running the same set of commands at each boot, it's > not clear to me how changing the order helps, but I don't necessarily > disagree with that change. It's the same point that Ian Lepore made about variance. Also http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix98.pdf page 9. [usenix98.pdf is one of the yarrow paper's references] > Thanks. In case it's not clear, please hold off on any further changes > until we have a better consensus on what the changes should be. The commit was 15 days ago, and its been 4 days since you started this thread. At this point you're the only one that has spoken up against the changes. Arthur and I have provided you our reasoning. I've provided references, pointed out the code, discussed my changes and reasoning with multiple security professionals at $WORK where we make products based on FreeBSD and have FIPS-140 Level 2 certificates[*]. I will only wait but so much longer before I feel there is near-unanimous consensus. -- -- David (obrien@FreeBSD.org) [*] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:07:54 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 791E6106566C; Thu, 6 Sep 2012 17:07:54 +0000 (UTC) Date: Thu, 6 Sep 2012 10:07:53 -0700 From: David O'Brien To: RW Message-ID: <20120906170753.GB14757@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120903005708.7082f230@gumby.homeunix.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-security@freebsd.org Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:07:54 -0000 *sigh*! > On Sun, 02 Sep 2012 15:20:31 -0700 RW, Why was Arthur and I dropped from the CC:? Please do not assume the folks directly involved are members and actively read what ever random mailing list a responce to a commit email gets moved to. We've been responding to Doug without knowing your replies existed. thanks, -- -- David From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:18:25 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 2ABB01065670; Thu, 6 Sep 2012 17:18:25 +0000 (UTC) Date: Thu, 6 Sep 2012 10:18:24 -0700 From: David O'Brien To: RW Message-ID: <20120906171824.GC14757@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120903005708.7082f230@gumby.homeunix.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:18:25 -0000 ** Please do not remove the CC: / FROM: recipients from replies ** On Mon, Sep 03, 2012 at 12:57:08AM +0100, RW wrote: > The more significant problem is that initrandom dumps some very > low-grade entropy into /dev/random before the entropy file (see below). > Since /dev/random has very limited buffering, and processes the buffers > in a timed loop, Arthur and I are aware of that. I believe this behavior of our yarrow implementation is poorly documented. > IMO the order should be reversed or the low-grade > stuff should be piped through sha256. We considered that. Arthur wanted to do it sooner, but I'm concerned about impact of multiple sha256 invocations on a large amount of data on low-end MIPS. I did some measurements on one of our lower-end Octeon MIPS devices and lowest-end ARM devices. My concerns are based on the Octeon MIPS result. I have zero concern for ARM devices [based on my very limited access to ARM devices]. [I don't have the results anymore thus they aren't supplied here] -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:27:52 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 5F9E1106566B; Thu, 6 Sep 2012 17:27:52 +0000 (UTC) Date: Thu, 6 Sep 2012 10:27:51 -0700 From: David O'Brien To: RW Message-ID: <20120906172751.GD14757@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120903013120.262a34fc@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120903013120.262a34fc@gumby.homeunix.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-security@freebsd.org Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:27:52 -0000 On Mon, Sep 03, 2012 at 01:31:20AM +0100, RW wrote: > I see that in CURRENT the order is reversed, but it's still repeating > the same problem of saturating the buffers. Now most of of the > low-grade entropy is going to be lost include the date, which in almost > all cases would have eliminated any problem with a reused entropy file. Given the limited buffer space we have, I'm not sure what else we could do. Artifically delay the better_than_nothing()? That seems too fragile and hackish. Arthur wanted to commit this: --- initrandom 2012-09-05 13:38:13.000000000 -0700 +++ initrandom,amesh 2012-08-22 16:54:03.000000000 -0700 @@ -18,6 +18,8 @@ feed_dev_random() { if [ -f "${1}" -a -r "${1}" -a -s "${1}" ]; then cat "${1}" | dd of=/dev/random bs=8k 2>/dev/null + else + return 1 fi } @@ -72,16 +69,16 @@ initrandom_start() # case ${entropy_file} in [Nn][Oo] | '') + better_than_nothing ;; *) if [ -w /dev/random ]; then - feed_dev_random "${entropy_file}" + feed_dev_random "${entropy_file}" \ + || better_than_nothing fi ;; esac - better_than_nothing - echo -n ' kickstart' fi to reduce what could be the useless better_than_nothing() run. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:30:43 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 79027106566C; Thu, 6 Sep 2012 17:30:43 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 30C368FC14; Thu, 6 Sep 2012 17:30:43 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id C57E06359; Thu, 6 Sep 2012 19:30:35 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 66866825F; Thu, 6 Sep 2012 19:30:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> Date: Thu, 06 Sep 2012 19:30:34 +0200 In-Reply-To: <20120906164514.GA14757@dragon.NUXI.org> (David O'Brien's message of "Thu, 6 Sep 2012 09:45:14 -0700") Message-ID: <867gs7qcsl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray 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: Thu, 06 Sep 2012 17:30:43 -0000 David O'Brien writes: > Doug Barton writes: > > I'll have to give the kenv output a look. I would also like to > > confirm that it's available on all platforms. > Geez, I'm not that stupid. Do you see any guards within bin/Makefile > that only build it for for some architectures? Of course kenv is available on all platforms - it's the underlying mechanism for tunables! However, it does not vary from one boot to another, or even from one machine to another if they run the same FreeBSD version with the same device.hints and loader.conf on the same hardware configuration. (with the possible exception of a serial number if the SMBIOS provides one, but I have a room full of identical servers which all have serial number 123456) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:42:48 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id A276D1065672; Thu, 6 Sep 2012 17:42:48 +0000 (UTC) Date: Thu, 6 Sep 2012 10:42:47 -0700 From: David O'Brien To: Peter Jeremy Message-ID: <20120906174247.GB13179@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120904220754.GA3643@server.rulingia.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org, Doug Barton , freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:42:48 -0000 On Wed, Sep 05, 2012 at 08:07:54AM +1000, Peter Jeremy wrote: > >What if, instead of replacing /entropy, we add an additional file in > >/var/db/entropy at boot time that is numerically 1 higher than > >$entropy_save_num ? > > That sounds like a reasonable idea. I don't see what that adds or fixes. It does not correct the possible reuse of seed material. It also increases the size of '/entropy' beyond 4k. How much do we want to stuff in at one time vs. gather over time? -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:42:51 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D08106566C; Thu, 6 Sep 2012 17:42:51 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 556858FC18; Thu, 6 Sep 2012 17:42:51 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 700EE6366; Thu, 6 Sep 2012 19:42:50 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 3A8808262; Thu, 6 Sep 2012 19:42:50 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120906171824.GC14757@dragon.NUXI.org> Date: Thu, 06 Sep 2012 19:42:49 +0200 In-Reply-To: <20120906171824.GC14757@dragon.NUXI.org> (David O'Brien's message of "Thu, 6 Sep 2012 10:18:24 -0700") Message-ID: <86392vqc86.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 17:42:51 -0000 David O'Brien writes: > RW writes: > > IMO the order should be reversed or the low-grade stuff should be > > piped through sha256. > We considered that. Arthur wanted to do it sooner, but I'm concerned > about impact of multiple sha256 invocations on a large amount of data > on low-end MIPS. Is there a reason to choose sha256 over a weaker, faster hash? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:57:48 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id 3FCF91065670; Thu, 6 Sep 2012 17:57:48 +0000 (UTC) Date: Thu, 6 Sep 2012 10:57:47 -0700 From: David O'Brien To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20120906175747.GC13179@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <86y5kpcqc4.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86y5kpcqc4.fsf@ds4.des.no> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:57:48 -0000 On Wed, Sep 05, 2012 at 01:37:15AM +0200, Dag-Erling Smrgrav wrote: > Speaking of rc.d and entropy, is the following code in /etc/rc.d/sshd > really necessary? > seeded=`sysctl -n kern.random.sys.seeded 2>/dev/null` > if [ "x${seeded}" != "x" ] && [ ${seeded} -eq 0 ] ; then > warn "Setting entropy source to blocking mode." ... > echo "Just hit for fast+insecure startup." > echo "====================================================" > sysctl kern.random.sys.seeded=0 2>/dev/null > read -t ${timeout} junk > echo "${junk}" `sysctl -a` `date` > /dev/random Likely this is inspired by 3.2 'How Compromises are Exploited', 'Compromise of High-Value Keys Generated From Compromised Key' paragraph. If the key that is being generated is vary valuable, the harm to the system owner can be very large. ... When we are about to generate a very valuable key, it is preferable to have what ever extra entropy there is in the PRNG's key. Therefore, the user can request en explicit reseed of the generator. Now that we have 'postrandom' possibly we should utilize the ${entropy_file} (and call postrandom again). Certainly [re]seeding with 'sysctl -a' and 'date' is poor and should be changed. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 17:19:25 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 7A5A7106564A; Thu, 6 Sep 2012 17:19:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 369438FC08; Thu, 6 Sep 2012 17:19:25 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q86HJORa002981; Thu, 6 Sep 2012 11:19:24 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q86HJL55043932; Thu, 6 Sep 2012 11:19:21 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: obrien@freebsd.org In-Reply-To: <20120906164514.GA14757@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 06 Sep 2012 11:19:21 -0600 Message-ID: <1346951961.59094.158.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Sep 2012 18:15:17 +0000 Cc: Arthur Mesh , freebsd-security@freebsd.org, Doug Barton , freebsd-rc@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: Thu, 06 Sep 2012 17:19:25 -0000 On Thu, 2012-09-06 at 09:45 -0700, David O'Brien wrote: > > > I'll have to give the kenv output a look. I would > > also like to confirm that it's available on all platforms. > > Geez, I'm not that stupid. Do you see any guards within bin/Makefile > that only build it for for some architectures? I verified we have it > on > MIPS, ARM, and PowerPC and gives some output. It does not give as > much > system-specific output as on x86 -- I wish it did, but the output can > be > rather unique on x86 it is worth including it. > 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. 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. 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. Beyond that, I think a facility that lets a specialized embedded system provide an alternate command sequence for seeding covers the rest of the needs of embedded systems well enough. -- Ian From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:21:17 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 664) id 4F1C21065670; Thu, 6 Sep 2012 18:21:17 +0000 (UTC) Date: Thu, 6 Sep 2012 11:21:16 -0700 From: David O'Brien To: Ian Lepore Message-ID: <20120906182116.GD13179@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> <20120905204050.GB820@dragon.NUXI.org> <1346945964.59094.147.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1346945964.59094.147.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.ORG, Doug Barton , freebsd-rc@FreeBSD.ORG, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:21:17 -0000 On Thu, Sep 06, 2012 at 09:39:24AM -0600, Ian Lepore wrote: > On Wed, 2012-09-05 at 13:40 -0700, David O'Brien wrote: > Of those oids you listed above, the vm and vfs generate a lot of text > but it's mostly the vm.stats part that changes. The kern.geom output is > pretty static on a given system, and oddly it takes a long time to > generate compared to other oids. The cp_time is already included in > cp_times. The dev.cpu is intel-specific. I'm not seeing that 'cp_time's specific values are in 'cp_times'. I have not looked at how easy it is to derive 'cp_time' given 'cp_times' output. > > 0.30s - Your list above > 0.18s - Your list minus kern.cp_time and vfs, changing vm to vm.stats > 0.05s - Also remove kern.geom Below is the diff between two different boots of my sysctl MIB list. I did not dig into why, but kern.geom varies between boots. As did other vm (non-vm.stats) values. The impact of formatting 'kern.geom.confdot' and XML formatting of 'kern.geom.confxml' is likely the large part of the .13s difference. Can you measure my list minus kern.geom (keeping kern.cp_time and vfs and vm). > So, to reiterate, this is the set of oids that takes only .05s: > kern.cp_times kern.lastpid kern.timecounter kern.tty_nout > kern.tty_nin vm.stats At this point I am liking: sysctl kern.cp_times kern.cp_time kern.lastpid kern.timecounter \ kern.tty_nout kern.tty_nin vm vfs debug dev.cpu \ | tr -Cd '0123456789xabcdef' -- -- David (obrien@FreeBSD.org) @@ -1,2 +1,2 @@ -kern.cp_times: 4 0 568 3 548 22 0 36 42 397 -kern.cp_time: 26 0 604 45 945 +kern.cp_times: 102 0 636 6 8801479 104 0 126 52 8801316 +kern.cp_time: 206 0 762 58 17602795 @@ -33 +33 @@ z0xfffffe000b134300 [shape=box,label="DI -z0xfffffe000b133d00 [shape=hexagon,label="ada0\nr1w1e3\nerr#0"]; +z0xfffffe000b133d00 [shape=hexagon,label="ada0\nr2w2e5\nerr#0"]; @@ -144 +144 @@ z0xfffffe000b188700 [shape=box,label="PA -z0xfffffe000b188300 [label="r1w1e2"]; +z0xfffffe000b188300 [label="r2w2e3"]; @@ -147 +147 @@ z0xfffffe000b188700 -> z0xfffffe000b1883 -z0xfffffe000b158b00 [shape=hexagon,label="ada0s1b\nr0w0e0\nerr#0"]; +z0xfffffe000b158b00 [shape=hexagon,label="ada0s1b\nr1w1e0\nerr#0"]; @@ -152 +152 @@ z0xfffffe000b18e100 [shape=box,label="PA -z0xfffffe000b18db00 [label="r1w1e3"]; +z0xfffffe000b18db00 [label="r2w2e5"]; @@ -161 +161 @@ z0xfffffe000b18c900 -> z0xfffffe000b18e1 -z0xfffffe000b18cd00 [shape=hexagon,label="ada0s1\nr1w1e2\nerr#0"]; +z0xfffffe000b18cd00 [shape=hexagon,label="ada0s1\nr2w2e3\nerr#0"]; @@ -184,0 +185,4 @@ z0xfffffe000b1f5500 -> z0xfffffe000b1e8d +z0xfffffe000b204900 [shape=box,label="SWAP\nswap\nr#4"]; +z0xfffffe000b204500 [label="r1w1e0"]; +z0xfffffe000b204500 -> z0xfffffe000b158b00; +z0xfffffe000b204900 -> z0xfffffe000b204500; @@ -240 +244 @@ kern.geom.confxml: - r1w1e3 + r2w2e5 @@ -700 +704 @@ kern.geom.confxml: - r1w1e2 + r2w2e3 @@ -706 +710 @@ kern.geom.confxml: - r0w0e0 + r1w1e0 @@ -758 +762 @@ kern.geom.confxml: - r1w1e3 + r2w2e5 @@ -818 +822 @@ kern.geom.confxml: - r1w1e2 + r2w2e3 @@ -944,0 +949,10 @@ kern.geom.confxml: + + + swap + 4 + + + + r1w1e0 + + @@ -975 +989 @@ kern.geom.raid.raid1e.rebuild_slab_size: -kern.lastpid: 51 +kern.lastpid: 134 @@ -982 +996 @@ kern.timecounter.tc.i8254.mask: 65535 -kern.timecounter.tc.i8254.counter: 43141 +kern.timecounter.tc.i8254.counter: 21189 @@ -986 +1000 @@ kern.timecounter.tc.HPET.mask: 429496729 -kern.timecounter.tc.HPET.counter: 253448303 +kern.timecounter.tc.HPET.counter: 386878246 @@ -990 +1004 @@ kern.timecounter.tc.ACPI-fast.mask: 1677 -kern.timecounter.tc.ACPI-fast.counter: 4125532 +kern.timecounter.tc.ACPI-fast.counter: 3928587 @@ -994 +1008 @@ kern.timecounter.tc.TSC-low.mask: 429496 -kern.timecounter.tc.TSC-low.counter: 677311549 +kern.timecounter.tc.TSC-low.counter: 848167747 @@ -999,2 +1013,2 @@ kern.timecounter.invariant_tsc: 1 -kern.tty_nout: 259 -kern.tty_nin: 0 +kern.tty_nout: 11221 +kern.tty_nin: 317 @@ -1006 +1020 @@ Virtual Memory: (Total: 1073859128K Act -Real Memory: (Total: 105764K Active: 10752K) +Real Memory: (Total: 107320K Active: 10856K) @@ -1008,2 +1022,2 @@ Shared Virtual Memory: (Total: 13964K Ac -Shared Real Memory: (Total: 9388K Active: 1184K) -Free Memory Pages: 2834004K +Shared Real Memory: (Total: 9404K Active: 1200K) +Free Memory Pages: 2828664K @@ -1011 +1025 @@ Free Memory Pages: 2834004K -vm.loadavg: { 3.54 0.78 0.28 } +vm.loadavg: { 0.00 0.00 0.00 } @@ -1022,2 +1036,2 @@ vm.md_malloc_wait: 0 -vm.kmem_map_free: 3055230976 -vm.kmem_map_size: 6223388672 +vm.kmem_map_free: 3054096384 +vm.kmem_map_size: 6224523264 @@ -1029,2 +1043,2 @@ vm.redzone.panic: 0 -vm.redzone.extra_mem: 19765344 -vm.nswapdev: 0 +vm.redzone.extra_mem: 19775024 +vm.nswapdev: 1 @@ -1035 +1049 @@ vm.swap_reserved: 47616000 -vm.swap_total: 0 +vm.swap_total: 8493465600 @@ -1060 +1074 @@ vm.exec_map_entries: 16 -vm.stats.misc.zero_page_count: 1 +vm.stats.misc.zero_page_count: 28 @@ -1064,2 +1078,2 @@ vm.stats.vm.v_rforkpages: 0 -vm.stats.vm.v_vforkpages: 350 -vm.stats.vm.v_forkpages: 1132 +vm.stats.vm.v_vforkpages: 1257 +vm.stats.vm.v_forkpages: 3781 @@ -1068,2 +1082,2 @@ vm.stats.vm.v_rforks: 0 -vm.stats.vm.v_vforks: 10 -vm.stats.vm.v_forks: 23 +vm.stats.vm.v_vforks: 36 +vm.stats.vm.v_forks: 80 @@ -1075 +1089 @@ vm.stats.vm.v_cache_count: 0 -vm.stats.vm.v_inactive_count: 564 +vm.stats.vm.v_inactive_count: 1045 @@ -1077,3 +1091,3 @@ vm.stats.vm.v_inactive_target: 30391 -vm.stats.vm.v_active_count: 4302 -vm.stats.vm.v_wire_count: 41709 -vm.stats.vm.v_free_count: 708500 +vm.stats.vm.v_active_count: 4383 +vm.stats.vm.v_wire_count: 42469 +vm.stats.vm.v_free_count: 707165 @@ -1085,2 +1099,2 @@ vm.stats.vm.v_page_size: 4096 -vm.stats.vm.v_tfree: 58362 -vm.stats.vm.v_pfree: 1604 +vm.stats.vm.v_tfree: 203414 +vm.stats.vm.v_pfree: 10339 @@ -1092 +1106 @@ vm.stats.vm.v_reactivated: 0 -vm.stats.vm.v_intrans: 4 +vm.stats.vm.v_intrans: 5 @@ -1094 +1108 @@ vm.stats.vm.v_vnodepgsout: 0 -vm.stats.vm.v_vnodepgsin: 576 +vm.stats.vm.v_vnodepgsin: 1115 @@ -1096 +1110 @@ vm.stats.vm.v_vnodeout: 0 -vm.stats.vm.v_vnodein: 59 +vm.stats.vm.v_vnodein: 120 @@ -1102,11 +1116,11 @@ vm.stats.vm.v_ozfod: 0 -vm.stats.vm.v_zfod: 48275 -vm.stats.vm.v_cow_optim: 3 -vm.stats.vm.v_cow_faults: 954 -vm.stats.vm.v_vm_faults: 65943 -vm.stats.sys.v_soft: 520 -vm.stats.sys.v_intr: 150022 -vm.stats.sys.v_syscall: 40465 -vm.stats.sys.v_trap: 53007 -vm.stats.sys.v_swtch: 9919 -vm.stats.object.bypasses: 7 -vm.stats.object.collapses: 67 +vm.stats.vm.v_zfod: 183444 +vm.stats.vm.v_cow_optim: 12 +vm.stats.vm.v_cow_faults: 3446 +vm.stats.vm.v_vm_faults: 217442 +vm.stats.sys.v_soft: 3223136 +vm.stats.sys.v_intr: 3339722 +vm.stats.sys.v_syscall: 195460 +vm.stats.sys.v_trap: 202403 +vm.stats.sys.v_swtch: 9642368 +vm.stats.object.bypasses: 16 +vm.stats.object.collapses: 257 @@ -1155,10 +1169,10 @@ FREE LIST 0: - 11 ( 8192K) | 1 | 1 | 0 - 10 ( 4096K) | 1 | 1 | 0 - 9 ( 2048K) | 0 | 0 | 0 - 8 ( 1024K) | 1 | 0 | 0 - 7 ( 512K) | 0 | 0 | 0 - 6 ( 256K) | 1 | 1 | 0 - 5 ( 128K) | 1 | 0 | 0 - 4 ( 64K) | 0 | 1 | 0 - 3 ( 32K) | 0 | 0 | 0 - 2 ( 16K) | 0 | 1 | 0 + 11 ( 8192K) | 0 | 1 | 0 + 10 ( 4096K) | 1 | 0 | 0 + 9 ( 2048K) | 1 | 1 | 0 + 8 ( 1024K) | 1 | 1 | 0 + 7 ( 512K) | 1 | 1 | 0 + 6 ( 256K) | 0 | 1 | 0 + 5 ( 128K) | 2 | 0 | 0 + 4 ( 64K) | 2 | 1 | 0 + 3 ( 32K) | 1 | 3 | 0 + 2 ( 16K) | 0 | 4 | 0 @@ -1191 +1205 @@ LEVEL SIZE NUMBER - -1: 37264K, 23 + -1: 37892K, 23 @@ -1193 +1207 @@ LEVEL SIZE NUMBER -vm.reserv.freed: 154 +vm.reserv.freed: 602 @@ -1199,2 +1213,2 @@ vm.pmap.pdpe.demotions: 0 -vm.pmap.pde.promotions: 129 -vm.pmap.pde.p_failures: 10168 +vm.pmap.pde.promotions: 415 +vm.pmap.pde.p_failures: 21525 @@ -1202 +1216 @@ vm.pmap.pde.mappings: 0 -vm.pmap.pde.demotions: 60 +vm.pmap.pde.demotions: 223 @@ -1208 +1222 @@ vfs.ufs.dirhash_docheck: 0 -vfs.ufs.dirhash_mem: 55412 +vfs.ufs.dirhash_mem: 58917 @@ -1266 +1280 @@ vfs.getnewbufrestarts: 0 -vfs.getnewbufcalls: 1437 +vfs.getnewbufcalls: 1585 @@ -1269 +1283 @@ vfs.lofreebuffers: 1122 -vfs.numfreebuffers: 20093 +vfs.numfreebuffers: 20091 @@ -1273 +1287 @@ vfs.lodirtybuffers: 2524 -vfs.numdirtybuffers: 25 +vfs.numdirtybuffers: 27 @@ -1282 +1296 @@ vfs.buffreekvacnt: 0 -vfs.bufreusecnt: 1436 +vfs.bufreusecnt: 1557 @@ -1286 +1300 @@ vfs.maxmallocbufspace: 16447897 -vfs.bufmallocspace: 0 +vfs.bufmallocspace: 2048 @@ -1288 +1302 @@ vfs.maxbufspace: 329613312 -vfs.bufspace: 23527424 +vfs.bufspace: 25509888 @@ -1291 +1305 @@ vfs.vmiodirenable: 1 -vfs.cache.numfullpathfound: 2 +vfs.cache.numfullpathfound: 48 @@ -1295 +1309 @@ vfs.cache.numfullpathfail1: 0 -vfs.cache.numfullpathcalls: 2 +vfs.cache.numfullpathcalls: 48 @@ -1297,12 +1311,12 @@ vfs.cache.numupgrades: 0 -vfs.cache.numneghits: 57 -vfs.cache.numnegzaps: 0 -vfs.cache.numposhits: 995 -vfs.cache.numposzaps: 1 -vfs.cache.nummisszap: 0 -vfs.cache.nummiss: 293 -vfs.cache.numchecks: 1053 -vfs.cache.dotdothits: 0 -vfs.cache.dothits: 1 -vfs.cache.numcalls: 1347 -vfs.cache.numcache: 228 -vfs.cache.numneg: 14 +vfs.cache.numneghits: 267 +vfs.cache.numnegzaps: 11 +vfs.cache.numposhits: 4967 +vfs.cache.numposzaps: 31 +vfs.cache.nummisszap: 26 +vfs.cache.nummiss: 558 +vfs.cache.numchecks: 5276 +vfs.cache.dotdothits: 9 +vfs.cache.dothits: 41 +vfs.cache.numcalls: 5910 +vfs.cache.numcache: 279 +vfs.cache.numneg: 17 @@ -1316 +1330 @@ vfs.usermount: 0 -vfs.worklist_len: 12 +vfs.worklist_len: 13 @@ -1318 +1332 @@ vfs.timestamp_precision: 0 -vfs.reassignbufcalls: 25 +vfs.reassignbufcalls: 285 @@ -1320 +1334 @@ vfs.vlru_allow_cache_src: 0 -vfs.freevnodes: 4 +vfs.freevnodes: 14 @@ -1322 +1336 @@ vfs.wantfreevnodes: 31771 -vfs.numvnodes: 233 +vfs.numvnodes: 295 @@ -1397 +1411 @@ debug.sx.retries: 10 -debug.to_avg_mpcalls: 833 +debug.to_avg_mpcalls: 1236 @@ -1399,2 +1413,2 @@ debug.to_avg_lockcalls: 0 -debug.to_avg_gcalls: 488 -debug.to_avg_depth: 1533 +debug.to_avg_gcalls: 727 +debug.to_avg_depth: 2020 @@ -1416,3 +1430,3 @@ debug.vfscache: 1 -debug.numcachehv: 20 -debug.numcache: 228 -debug.numneg: 14 +debug.numcachehv: 28 +debug.numcache: 279 +debug.numneg: 17 @@ -1422 +1436 @@ debug.rush_requests: 0 -debug.vn_io_faults: 0 +debug.vn_io_faults: 3 @@ -1444,3 +1458,3 @@ debug.softdep.jaddref_rollback: 0 -debug.softdep.dir_entry: 0 -debug.softdep.direct_blk_ptrs: 0 -debug.softdep.inode_bitmap: 0 +debug.softdep.dir_entry: 6 +debug.softdep.direct_blk_ptrs: 1 +debug.softdep.inode_bitmap: 6 @@ -1475 +1489 @@ debug.softdep.write.freefile: 0 -debug.softdep.write.freeblks: 0 +debug.softdep.write.freeblks: 7 @@ -1479 +1493 @@ debug.softdep.write.indirdep: 0 -debug.softdep.write.allocdirect: 0 +debug.softdep.write.allocdirect: 42 @@ -1481,3 +1495,3 @@ debug.softdep.write.newblk: 0 -debug.softdep.write.bmsafemap: 0 -debug.softdep.write.inodedep: 0 -debug.softdep.write.pagedep: 0 +debug.softdep.write.bmsafemap: 17 +debug.softdep.write.inodedep: 91 +debug.softdep.write.pagedep: 16 @@ -1500 +1514 @@ debug.softdep.current.mkdir: 0 -debug.softdep.current.diradd: 9 +debug.softdep.current.diradd: 10 @@ -1509,2 +1523,2 @@ debug.softdep.current.bmsafemap: 2 -debug.softdep.current.inodedep: 10 -debug.softdep.current.pagedep: 2 +debug.softdep.current.inodedep: 11 +debug.softdep.current.pagedep: 3 @@ -1523,8 +1537,8 @@ debug.softdep.total.freedep: 0 -debug.softdep.total.freework: 0 -debug.softdep.total.newdirblk: 0 -debug.softdep.total.dirrem: 1 -debug.softdep.total.mkdir: 0 -debug.softdep.total.diradd: 10 -debug.softdep.total.freefile: 1 -debug.softdep.total.freeblks: 0 -debug.softdep.total.freefrag: 27 +debug.softdep.total.freework: 8 +debug.softdep.total.newdirblk: 1 +debug.softdep.total.dirrem: 35 +debug.softdep.total.mkdir: 2 +debug.softdep.total.diradd: 59 +debug.softdep.total.freefile: 16 +debug.softdep.total.freeblks: 7 +debug.softdep.total.freefrag: 83 @@ -1534,4 +1548,4 @@ debug.softdep.total.allocdirect: 0 -debug.softdep.total.newblk: 97 -debug.softdep.total.bmsafemap: 10 -debug.softdep.total.inodedep: 11 -debug.softdep.total.pagedep: 2 +debug.softdep.total.newblk: 305 +debug.softdep.total.bmsafemap: 48 +debug.softdep.total.inodedep: 68 +debug.softdep.total.pagedep: 13 @@ -1569 +1583 @@ dev.cpu.0.cx_lowest: C1 -dev.cpu.0.cx_usage: 100.00% last 679us +dev.cpu.0.cx_usage: 100.00% last 785us @@ -1577 +1591 @@ dev.cpu.1.cx_lowest: C1 -dev.cpu.1.cx_usage: 100.00% last 801us +dev.cpu.1.cx_usage: 100.00% last 89us From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:25:40 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E1F106566B; Thu, 6 Sep 2012 18:25:40 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 810268FC0C; Thu, 6 Sep 2012 18:25:40 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id B5794638E; Thu, 6 Sep 2012 20:25:39 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 84727826F; Thu, 6 Sep 2012 20:25:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <86y5kpcqc4.fsf@ds4.des.no> <20120906175747.GC13179@dragon.NUXI.org> Date: Thu, 06 Sep 2012 20:25:39 +0200 In-Reply-To: <20120906175747.GC13179@dragon.NUXI.org> (David O'Brien's message of "Thu, 6 Sep 2012 10:57:47 -0700") Message-ID: <86y5knovoc.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 18:25:40 -0000 David O'Brien writes: > Dag-Erling Smrgrav writes: > > Speaking of rc.d and entropy, is the following code in /etc/rc.d/sshd > > really necessary? > > seeded=3D`sysctl -n kern.random.sys.seeded 2>/dev/null` > > if [ "x${seeded}" !=3D "x" ] && [ ${seeded} -eq 0 ] ; then > > warn "Setting entropy source to blocking mode." > [...] > Likely this is inspired by 3.2 'How Compromises are Exploited', > 'Compromise of High-Value Keys Generated From Compromised Key' paragraph. > > If the key that is being generated is vary valuable, the harm to the > system owner can be very large. These are host keys. I'd say they're moderately valuable - depending on the machine and your point of view, they may be more or less valuable than user keys - but they are usually generated under controlled circumstances, rather than circumstances in which an attacker may be able to influence the PRNG. > Now that we have 'postrandom' possibly we should utilize the > ${entropy_file} (and call postrandom again). > > Certainly [re]seeding with 'sysctl -a' and 'date' is poor and should be > changed. Well, currently it's a no-op since kern.random.sys.seeded is never 0 at that point, if I understand correctly. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:27:30 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 AD794106567E; Thu, 6 Sep 2012 18:27:30 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 684808FC20; Thu, 6 Sep 2012 18:27:30 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 74F6B6391; Thu, 6 Sep 2012 20:27:29 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 4A4E48271; Thu, 6 Sep 2012 20:27:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Arthur Mesh References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120906171824.GC14757@dragon.NUXI.org> <86392vqc86.fsf@ds4.des.no> <20120906181922.GA89120@x96.org> Date: Thu, 06 Sep 2012 20:27:28 +0200 In-Reply-To: <20120906181922.GA89120@x96.org> (Arthur Mesh's message of "Thu, 6 Sep 2012 11:19:22 -0700") Message-ID: <86txvbovlb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 18:27:30 -0000 Arthur Mesh writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > Is there a reason to choose sha256 over a weaker, faster hash? > Given the fact that yarrow uses sha256 internally, I don't think it's a > sound idea to add weaker links to the chain. What can possibly be weaker than discarding most of the entropy provided by the administrator? David had a genuine concern about performance when stuffing large amounts of data into /dev/random. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:28:17 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id D434C1065676; Thu, 6 Sep 2012 18:28:17 +0000 (UTC) Date: Thu, 6 Sep 2012 11:28:16 -0700 From: David O'Brien To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20120906182816.GE13179@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120906171824.GC14757@dragon.NUXI.org> <86392vqc86.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86392vqc86.fsf@ds4.des.no> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:28:17 -0000 On Thu, Sep 06, 2012 at 07:42:49PM +0200, Dag-Erling Smrgrav wrote: > David O'Brien writes: > > RW writes: > > > IMO the order should be reversed or the low-grade stuff should be > > > piped through sha256. > > We considered that. Arthur wanted to do it sooner, but I'm concerned > > about impact of multiple sha256 invocations on a large amount of data > > on low-end MIPS. > > Is there a reason to choose sha256 over a weaker, faster hash? I see Arthur, But still wanted to give my own longer responce. Using a weaker hash could reduce the amount of entropy in the output (due to collisions). The Yarrow paper makes this argument (but willing to potentially loose some entropy) in 5 'The Generic Yarrow Design an Yarrow-160' The reason is if you take an 'm' bit random value and apply a hash function that produces 'm' bits of output, the result has less than 'm' bits of entropy due to the collisions that occur. This is a very minor effect, and overall results in the loss of at most a few bits of entropy. For a good entropy input I likely agree with you. But for the poor-grade entropy input I don't think we want to prematurely loose any of it. But I have not fully thought thru potential loss of entropy in a hash of a hash [where entropy was or wasn't lost]. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:31:28 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 83B9A106567B; Thu, 6 Sep 2012 18:31:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 41C828FC1A; Thu, 6 Sep 2012 18:31:28 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 0704D6397; Thu, 6 Sep 2012 20:31:27 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id C731A8273; Thu, 6 Sep 2012 20:31:26 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120906171824.GC14757@dragon.NUXI.org> <86392vqc86.fsf@ds4.des.no> <20120906182816.GE13179@dragon.NUXI.org> Date: Thu, 06 Sep 2012 20:31:26 +0200 In-Reply-To: <20120906182816.GE13179@dragon.NUXI.org> (David O'Brien's message of "Thu, 6 Sep 2012 11:28:16 -0700") Message-ID: <86pq5zovep.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 18:31:28 -0000 David O'Brien writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Is there a reason to choose sha256 over a weaker, faster hash? > Using a weaker hash could reduce the amount of entropy in the > output (due to collisions). > > The Yarrow paper makes this argument (but willing to potentially loose > some entropy) in 5 'The Generic Yarrow Design an Yarrow-160' > > The reason is if you take an 'm' bit random value and apply a hash > function that produces 'm' bits of output, the result has less than > 'm' bits of entropy due to the collisions that occur. This is a very > minor effect, and overall results in the loss of at most a few bits > of entropy. I was thinking along the lines of feeding at least 2 * m into the hash function, possibly much more. Remember that we're talking about finding an alternative to discarding large amounts of data. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:19:28 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35758106564A; Thu, 6 Sep 2012 18:19:28 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id F2FEA8FC15; Thu, 6 Sep 2012 18:19:27 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so3054577pbb.13 for ; Thu, 06 Sep 2012 11:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VR5jM8t02yZcW4r26tKjZOx3h6AV+wW7yzRpm8HPW0Q=; b=V1Cdgfvl0me/lfko5my1iNAhrpJwxqT69zmzTco/dxnuE/6aY6cnJ7OezxRuGWALN/ PmXPL1ajtxnm/wZnXmXodmKaevXSQlhfISL0U33LTQVEv6C0SxJL3BjddBGBnuQgEG9d EB+bB4Hdj2id4yTn3qaL7Xjyj/BBBsrhe6K1zCQZYbx1+iJiCfklLCbEW9rdG0C9kxrJ xDH1UF/kX+gYNnEx69iRe4pPTlu+llQcu9RfbrlLtwDlgVDPTuO2xK6BYq9yM5aC9qYQ dAGUZMynZY2iWja3PVfRW9RHKwVmG8rDWrqKXEZ1mnRsQ+paI52e5tzuS2PIJQjZuD67 GQpA== Received: by 10.68.213.138 with SMTP id ns10mr5551492pbc.157.1346955567738; Thu, 06 Sep 2012 11:19:27 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id kt2sm1712915pbc.73.2012.09.06.11.19.24 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 11:19:27 -0700 (PDT) Date: Thu, 6 Sep 2012 11:19:22 -0700 From: Arthur Mesh To: Dag-Erling Sm??rgrav Message-ID: <20120906181922.GA89120@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120906171824.GC14757@dragon.NUXI.org> <86392vqc86.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86392vqc86.fsf@ds4.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 06 Sep 2012 18:31:43 +0000 Cc: freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 18:19:28 -0000 On Thu, Sep 06, 2012 at 07:42:49PM +0200, Dag-Erling Sm??rgrav wrote: > Is there a reason to choose sha256 over a weaker, faster hash? Given the fact that yarrow uses sha256 internally, I don't think it's a sound idea to add weaker links to the chain. From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:44:02 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id 47461106566B; Thu, 6 Sep 2012 18:44:02 +0000 (UTC) Date: Thu, 6 Sep 2012 11:44:00 -0700 From: David O'Brien To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20120906184400.GF13179@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867gs7qcsl.fsf@ds4.des.no> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:44:02 -0000 On Thu, Sep 06, 2012 at 07:30:34PM +0200, Dag-Erling Smrgrav wrote: > However, it does not vary from one boot to another, or even from one > machine to another if they run the same FreeBSD version with the same > device.hints and loader.conf on the same hardware configuration. ... and same BIOS version. I found on some Dell desktops and HP servers I looked at that the 'hint.acpi.0' MIB could vary depending on BIOS version, and 'smbios' MIB did vary between systems. > (with the possible exception of a serial number if the SMBIOS provides > one, but I have a room full of identical servers which all have serial > number 123456) I do not doubt what you say for SuperMicro or similar "white box" systems. On $WORKS's ARM and MIPS devices there was also some differences, but granted not as much as on x86. better_than_nothing() is a best attempt. For instance, have you looked at how close the 'ps -fauxww' output is between systems? I don't see much variance. I'm not saying 'kenv' is perfect, but it was something I found in /[s]bin that varied between systems so it was a good replacement for one of the 'ps' runs. There are several attacker scenarios to think of. 1. Attacker has no login on the victim system, but is working from anything probeable over the network (including sniffed network traffic). 2. Attacker has a local non-root login on the victim system. 3. Attacker no login on the victim system, but knows its exact hardware and software configuration and can study their copy of the victim system. 4. Attacker has a local [intruded] root login on the victim system. [Not to be dismissed as "well they have root -- game over", assume a key securely moved off box is being attacked.] We cannot guard against all of them, but we should try to have output in better_than_nothing() to help guard against all of these. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 18:39:21 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C4051065672; Thu, 6 Sep 2012 18:39:21 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4421D8FC0A; Thu, 6 Sep 2012 18:39:20 +0000 (UTC) Received: by dadr6 with SMTP id r6so1314577dad.13 for ; Thu, 06 Sep 2012 11:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WKcjHoJs2OptUXHg/4HHYaluK/D/TdrN6d5DkGERzkI=; b=D44V/zKU3obaiWGFJ5hLajyvxQAOZaFWejwuRWQ+AKfOFcOEkmtt/MfLPc2GX+CMwY dl/d5AqKuzkfs4DyZX+chr1CkKcpodo2vXBmITUC04wZC+1xhB+3n7BXA/ub27q75hrD 9Px7QaOUzDZPu8yh9RMKcI4SP99IX3VFrOI4sjdG07Y84bjxeaiWkfSkId0iui1AZnpB 7RXI/Oa8DVP9V+6qombZEroItcBG8NmrC/YHeNPy+THI/T60kfqutKBd5VU2TKsFcXAu 6qZgBejfxveHCpFC8xwf3iGxnGRswjjKZdUJSUWRfOjdsIKfczV//2CpYRd5qinPFBch WoVg== Received: by 10.68.116.17 with SMTP id js17mr5772925pbb.109.1346956760543; Thu, 06 Sep 2012 11:39:20 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id pq7sm1751356pbb.25.2012.09.06.11.39.17 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 11:39:19 -0700 (PDT) Date: Thu, 6 Sep 2012 11:39:15 -0700 From: Arthur Mesh To: Dag-Erling Sm??rgrav Message-ID: <20120906183915.GB89120@x96.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903005708.7082f230@gumby.homeunix.com> <20120906171824.GC14757@dragon.NUXI.org> <86392vqc86.fsf@ds4.des.no> <20120906181922.GA89120@x96.org> <86txvbovlb.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86txvbovlb.fsf@ds4.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 06 Sep 2012 18:44:21 +0000 Cc: freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 18:39:21 -0000 On Thu, Sep 06, 2012 at 08:27:28PM +0200, Dag-Erling Sm??rgrav wrote: > What can possibly be weaker than discarding most of the entropy provided > by the administrator? Almost nothing. > David had a genuine concern about performance > when stuffing large amounts of data into /dev/random. Sure, security and performance don't go together well very often. From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 19:02:40 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 4E0B7106567B; Thu, 6 Sep 2012 19:02:40 +0000 (UTC) Date: Thu, 6 Sep 2012 12:02:39 -0700 From: David O'Brien To: Ian Lepore Message-ID: <20120906190239.GG13179@dragon.NUXI.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1346951961.59094.158.camel@revolution.hippie.lan> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org, Doug Barton , freebsd-rc@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 Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:02:40 -0000 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. The FreeBSD kernel expects to be loaded by /boot/loader and for it to provided a suitable environment. 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. > 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. :-) > 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. 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. I don't want to see every command in better_than_nothing() turn into "test -x ___ && ___". -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 19:17:50 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 6F1C5106566B; Thu, 6 Sep 2012 19:17:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 49C8E8FC16; Thu, 6 Sep 2012 19:17:50 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 1D0061D004; Thu, 6 Sep 2012 12:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1346959064; bh=x3ZfAWTZQ/PSUtI+BsIysqbgpJbeG/C+Fc+blLeOPTw=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=hjJ+2UvBIBpzJvhCSHC9h/s5+f9uYeBz/AellMA/TlS0UfqTNKVZWI9xSOvqBYibp GL4YtTLeUgbo+etS2XXnrNVI1raCE2W4XAlm2IgcFAuieNsKJUY6DjwN3zUTeih2+h XsNEjkvN6uqm3cqn1F3TN/J3dXRZyFHvhNwMe8mA= Message-ID: <5048F6D4.4010502@delphij.net> Date: Thu, 06 Sep 2012 12:17:40 -0700 From: Xin Li Organization: The freeBSD Project User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.7) Gecko/20120830 Thunderbird/10.0.7 MIME-Version: 1.0 To: obrien@freebsd.org References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> <20120905204050.GB820@dragon.NUXI.org> <1346945964.59094.147.camel@revolution.hippie.lan> <20120906182116.GD13179@dragon.NUXI.org> In-Reply-To: <20120906182116.GD13179@dragon.NUXI.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , Ian Lepore , Doug Barton , freebsd-rc@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:17:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/06/12 11:21, David O'Brien wrote: > At this point I am liking: sysctl kern.cp_times kern.cp_time > kern.lastpid kern.timecounter \ kern.tty_nout kern.tty_nin vm vfs > debug dev.cpu \ | tr -Cd '0123456789xabcdef' I think you could use sysctl -n to remove the variable names (which is a good thing). I'm a little bit concerned with the fact that most of the characters here are numbers, would it be a good idea to filter it with e.g. gzip (my $.02) by the way before feeding into /dev/random? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQSPbUAAoJEG80Jeu8UPuzbhMIALHk35T6JEC7IKLTiAV6nxBU l+F0yZ+0qbVd2yOX88yYBYCQyMFPh0+6BXVSwTQoZu1W8mOfgZ72TuEBa6X3uhMW yUyr/jkLamAtcVS+Rofji30DKgHduLZlEwQDbpu1EGP1zaRL0ObSw9XOuzY0J6xO EsqN96K6a1+TfZ9kc6px5EgLdgjdbpt8eXkLG01kqfCEDiOMQAIL8rU2uHbes/jl xWSKwtY+ky+f6zHcy0eoSv1v5DQU5kxeXkvVCYDcE2PahOKHQ3zdjmEUhD3TLBQf OOvn6nSIyNK9t3islh0+v9nWFAYA8rKUFPPMbNSQvHABQ+MeqxAMdoMEx6HOdCU= =3uv3 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 19:19:43 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 3EBC71065672; Thu, 6 Sep 2012 19:19:43 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id ECEFD8FC23; Thu, 6 Sep 2012 19:19:42 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 38C1563C2; Thu, 6 Sep 2012 21:19:42 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id F077C827D; Thu, 6 Sep 2012 21:19:41 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> <20120906184400.GF13179@dragon.NUXI.org> Date: Thu, 06 Sep 2012 21:19:41 +0200 In-Reply-To: <20120906184400.GF13179@dragon.NUXI.org> (David O'Brien's message of "Thu, 6 Sep 2012 11:44:00 -0700") Message-ID: <86lignot6a.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray 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: Thu, 06 Sep 2012 19:19:43 -0000 David O'Brien writes: > Dag-Erling Sm=C3=B8rgrav writes: > > However, it does not vary from one boot to another, or even from one > > machine to another if they run the same FreeBSD version with the same > > device.hints and loader.conf on the same hardware configuration. > ... and same BIOS version. > > I found on some Dell desktops and HP servers I looked at that the > 'hint.acpi.0' MIB could vary depending on BIOS version, and 'smbios' > MIB did vary between systems. kenv(1) on the machine I'm typing this on produces 2128 bytes, less than 1% of which will vary between machines with the same motherboard. The UUID is all-zeroes except for the lower 48 bits, which are identical to the on-board NIC's MAC address. The BIOS version consists of two characters ("F8") and a release date ("01/08/2007"). If the attacker knows what motherboard I have, he can easily figure out the handful of possible BIOS revisions and release dates, and the first 24 bits of the MAC address (00:16:e6). The amount of installed memory may vary, but it is extremely likely to be the product of 1048576 and a smallish power of two (4, in this case). > I'm not saying 'kenv' is perfect, but it was something I found in > /[s]bin that varied between systems so it was a good replacement for > one of the 'ps' runs. ...except ps(1) varies between reboots and over time, especially if you include fields like majflt, minflt, nivcsw and nvcsw, and to a lesser extent systime and usertime (it would help if they had greater resolution); whereas kenv(1) does not and can be identical or nearly so on multiple machines. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 19:58:42 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 B7398106566B for ; Thu, 6 Sep 2012 19:58:42 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 443CB8FC08 for ; Thu, 6 Sep 2012 19:58:41 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q86Jwe6r073505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Sep 2012 05:58:40 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q86JwZRh029075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 05:58:35 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q86JwYIx029074; Fri, 7 Sep 2012 05:58:34 +1000 (EST) (envelope-from peter) Date: Fri, 7 Sep 2012 05:58:34 +1000 From: Peter Jeremy To: RW Message-ID: <20120906195834.GB6915@server.rulingia.com> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120905021248.5a17ace9@gumby.homeunix.com> <20120905212734.GE2654@aspire.rulingia.com> <20120906020934.2b97681d@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: <20120906020934.2b97681d@gumby.homeunix.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Thu, 06 Sep 2012 19:58:42 -0000 --+xNpyl7Qekk2NvDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Sep-06 02:09:34 +0100, RW wrote: >On Thu, 6 Sep 2012 07:27:34 +1000 >Peter Jeremy wrote: >> Is it worth splitting harvestfifo into multiple queues to prevent >> this? At least a separate queue for RANDOM_WRITE and potentially >> separate queues for each entropy source. > >It already does that. That's what the index "origin" is for. You're right, sorry. I misread the code. Please ignore my posting. --=20 Peter Jeremy --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBJAGoACgkQ/opHv/APuIeOhACffY/uGE/KkHrQxi8eZSrBrwo8 1/wAn14i45nZEwfvJlmeQwYrvB4nCih+ =0Bi4 -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 20:03:26 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id EBCBE1065679; Thu, 6 Sep 2012 20:03:26 +0000 (UTC) Date: Thu, 6 Sep 2012 13:03:25 -0700 From: David O'Brien To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20120906200325.GA17159@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> <20120906184400.GF13179@dragon.NUXI.org> <86lignot6a.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86lignot6a.fsf@ds4.des.no> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:03:27 -0000 On Thu, Sep 06, 2012 at 09:19:41PM +0200, Dag-Erling Smrgrav wrote: > David O'Brien writes: > > Dag-Erling Smørgrav writes: > > > However, it does not vary from one boot to another, or even from one > > > machine to another if they run the same FreeBSD version with the same > > > device.hints and loader.conf on the same hardware configuration. > > ... and same BIOS version. > > > > I found on some Dell desktops and HP servers I looked at that the > > 'hint.acpi.0' MIB could vary depending on BIOS version, and 'smbios' > > MIB did vary between systems. > > kenv(1) on the machine I'm typing this on produces 2128 bytes, less than > 1% of which will vary between machines with the same motherboard. DES, I am not sure what you are arguing. Are you asking for 'kenv' to be removed from better_than_nothing() ? Or are you just making sure folks are aware it is not a source of strong entropy? Currently 'kenv' does not have a way to display a specific MIB so its hard to reduce the output to just that which may vary. 'date' has 28 characters of output, well formed in such a way to reduce the search space. The variance alone in 'kenv' output on the tier-1 vendor machines I inspected had much more than that (> 100 characters). We could reduce the boiler plate by: kenv | sed 's/.*"\(.*\)"/\1/' which reduced 2786 bytes of output to 660 on an HP test machine. > The UUID is all-zeroes except for the lower 48 bits, which are > identical to the on-board NIC's MAC address. I'm seeing smbios.system.uuid="6c7e35be-5599-db11-ae96-39bc833c4d3c" -and- smbios.system.uuid="44454c4c-5200-1053-804a-b7c04f594631" I already acknowledged that smbios output can be crappy on some systems. The MAC is not in the 'kenv' output, so I'm not sure how that statement applies. > The BIOS version consists of two > characters ("F8") and a release date ("01/08/2007"). > If the attacker > knows what motherboard I have, he can easily figure out the handful of > possible BIOS revisions and release dates, and the first 24 bits of the > MAC address (00:16:e6). I already said an attacker could have a local login on the system. That would give them full knowledge of the kenv output. Same attacker can figure out the 'date' output from uptime, etc... > > I'm not saying 'kenv' is perfect, but it was something I found in > > /[s]bin that varied between systems so it was a good replacement for > > one of the 'pas' runs. > > ...except ps(1) varies between reboots and over time, especially if you > include fields like majflt, minflt, nivcsw and nvcsw, and to a lesser > extent systime and usertime (it would help if they had greater > resolution); whereas kenv(1) does not and can be identical or nearly so > on multiple machines. Does 'ps' vary that much across the two invocations that we had in 'initrandom'? Please post a diff to back up any "yes" answer. We already have an invocation of 'ps'. Please suggest a *different* command invocation. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 20:44:39 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 EDA20106566B; Thu, 6 Sep 2012 20:44:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9A08FC0C; Thu, 6 Sep 2012 20:44:39 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 795E21203BF; Thu, 6 Sep 2012 22:44:35 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 619632847B; Thu, 6 Sep 2012 22:44:35 +0200 (CEST) Date: Thu, 6 Sep 2012 22:44:35 +0200 From: Jilles Tjoelker To: David O'Brien Message-ID: <20120906204435.GA87795@stack.nl> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <1346638718.1140.573.camel@revolution.hippie.lan> <50451041.9070302@FreeBSD.org> <1346789717.1140.675.camel@revolution.hippie.lan> <20120905204050.GB820@dragon.NUXI.org> <1346945964.59094.147.camel@revolution.hippie.lan> <20120906182116.GD13179@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120906182116.GD13179@dragon.NUXI.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arthur Mesh , Ian Lepore , Doug Barton , freebsd-rc@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, Mark Murray 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: Thu, 06 Sep 2012 20:44:40 -0000 On Thu, Sep 06, 2012 at 11:21:16AM -0700, David O'Brien wrote: > On Thu, Sep 06, 2012 at 09:39:24AM -0600, Ian Lepore wrote: > > On Wed, 2012-09-05 at 13:40 -0700, David O'Brien wrote: > > Of those oids you listed above, the vm and vfs generate a lot of text > > but it's mostly the vm.stats part that changes. The kern.geom output is > > pretty static on a given system, and oddly it takes a long time to > > generate compared to other oids. The cp_time is already included in > > cp_times. The dev.cpu is intel-specific. > I'm not seeing that 'cp_time's specific values are in 'cp_times'. > I have not looked at how easy it is to derive 'cp_time' given > 'cp_times' output. That's trivial. The 'cp_time' output is the sum of the 'cp_times' output for all CPU cores. The 'cp_times' output has five numbers for each core. For example, in the '-' lines below, 568 + 36 = 604. > @@ -1,2 +1,2 @@ > -kern.cp_times: 4 0 568 3 548 22 0 36 42 397 > -kern.cp_time: 26 0 604 45 945 > +kern.cp_times: 102 0 636 6 8801479 104 0 126 52 8801316 > +kern.cp_time: 206 0 762 58 17602795 -- Jilles Tjoelker From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 21:36:43 2012 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 664) id 1609C1065674; Thu, 6 Sep 2012 21:36:43 +0000 (UTC) Date: Thu, 6 Sep 2012 14:36:42 -0700 From: David O'Brien To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Message-ID: <20120906213642.GA18396@dragon.NUXI.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> <20120906184400.GF13179@dragon.NUXI.org> <86lignot6a.fsf@ds4.des.no> <20120906200325.GA17159@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120906200325.GA17159@dragon.NUXI.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray Subject: Re: svn commit: r239598 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:36:43 -0000 On Thu, Sep 06, 2012 at 01:03:25PM -0700, David O'Brien (@FreeBSD) wrote: > I already said an attacker could have a local login on the system. > That would give them full knowledge of the kenv output. > Same attacker can figure out the 'date' output from uptime, etc... Note that this flies somewhat in the face of my argument for 'postrandom' based on Schneier's writings on deleting the seed file after it used. Please remember this is for better_than_nothing(). I like Arthur's patch that avoids calling better_than_nothing() if we feed_dev_random() with ${entropy_file}. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 22:02:04 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 AB33A106564A; Thu, 6 Sep 2012 22:02:04 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B70C48FC14; Thu, 6 Sep 2012 22:02:03 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1862292wgb.31 for ; Thu, 06 Sep 2012 15:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=5YJQoWcAQkzkExD3vNwch4plGCFhkgoJ4/j6rsS73Zk=; b=xNAVyPjOUiC3HE/akPV8aEQQGWdrU4ariyVXsIf8Wo+sIaUxw6usYNtZA0oI7U8lBb b0uq1lACxlROpa0DtUIrnG1z66VK36VbZBYWRfKlpr5oUftAAdK6kI/ykV3HTWCWBjed 7bTIOMVNqQp22Nfjp4X6YEdn499VUDUXSn1NwZxFGThoLI+/q6AhXKha8LEv/TSej/NU nRt3P0x/cgKzUZyEcOGYTy2dqv5Lq+KT0MEgtmZr+SbeQy0+7ocGRC0Wt1/zrwVpfig8 A5cW5Dw7vPuAQceeGZPt3O2vY1CJs1qpLXGcibIGcLwcO1r5JhSO5sBfH0sgsxodGWf6 N/zw== Received: by 10.180.99.196 with SMTP id es4mr48461161wib.18.1346968922382; Thu, 06 Sep 2012 15:02:02 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id t8sm6251370wiy.3.2012.09.06.15.01.59 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 15:02:01 -0700 (PDT) Date: Thu, 6 Sep 2012 23:01:57 +0100 From: RW To: obrien@freebsd.org Message-ID: <20120906230157.5307a21f@gumby.homeunix.com> In-Reply-To: <20120906174247.GB13179@dragon.NUXI.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Mesh , Doug Barton , freebsd-rc@freebsd.org, freebsd-security@freebsd.org, Arthur Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 22:02:04 -0000 On Thu, 6 Sep 2012 10:42:47 -0700 David O'Brien wrote: > On Wed, Sep 05, 2012 at 08:07:54AM +1000, Peter Jeremy wrote: > > >What if, instead of replacing /entropy, we add an additional file > > >in /var/db/entropy at boot time that is numerically 1 higher than > > >$entropy_save_num ? > > That sounds like a reasonable idea. > > I don't see what that adds or fixes. It does not correct the > possible reuse of seed material. Reusing a secure entropy file is only a problem if the complete history of yarrow, from boot until some significant output, is exactly the same as on a previous boot. Once something changes you get a completely different sequence of yarrow cipher-keys; a counter or writing out a new entropy file will both do this, but OTOH so will any difference in harvested entropy such a sub-nanosecond difference in timing. From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 22:42:35 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 73482106566C; Thu, 6 Sep 2012 22:42:35 +0000 (UTC) Date: Thu, 6 Sep 2012 15:42:34 -0700 From: David O'Brien To: RW Message-ID: <20120906224234.GA18953@dragon.NUXI.org> References: <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120906230157.5307a21f@gumby.homeunix.com> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org, freebsd-rc@freebsd.org, Doug Barton Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 22:42:35 -0000 On Thu, Sep 06, 2012 at 11:01:57PM +0100, RW wrote: > On Thu, 6 Sep 2012 10:42:47 -0700 David O'Brien wrote: > > On Wed, Sep 05, 2012 at 08:07:54AM +1000, Peter Jeremy wrote: > > > >What if, instead of replacing /entropy, we add an additional file > > > >in /var/db/entropy at boot time that is numerically 1 higher than > > > >$entropy_save_num ? > > > That sounds like a reasonable idea. > > > > I don't see what that adds or fixes. It does not correct the > > possible reuse of seed material. > > Reusing a secure entropy file is only a problem if the complete history > of yarrow, from boot until some significant output, is exactly the same > as on a previous boot. I feel this is discussed in the yarrow and Fortuna papers. Please provide specific section reference backing your position for me to read. Why are we trying to invent a new shiny way to address an issue discussed by yarrow's author? What is your specific argument against deleting the consumed seed file? Do you feel the 4k bytes of /entropy is too little? -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 22:47:10 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 43FAF106572D; Thu, 6 Sep 2012 22:47:08 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9128FC0C; Thu, 6 Sep 2012 22:47:08 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so3363878pbb.13 for ; Thu, 06 Sep 2012 15:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=h/ZJAWHfRojpQqizUUmlRV+ycQLuNEsBSv5ArtgXo3E=; b=tnNMQOEAj1HA5iMEVbq9Ag6N0Gi6bfwM1D20jXfZZ6aKjnDqpiFYrrfK1wi2aXHVrL MSFWL+RvF9oFYCIXW3ev9iiqRbydwucCSDJEt8QIX7/fQjunnKXtOVuIbEbDFKUG97Y8 JIqxc/oJjmCUpunv2FawKPoIXtV9kE8hJcBNfMlIg+ecTdxyJqycumPqge4hyRz+2pAZ n4GtwJpY5Yj0BMKcnx70whY2Zp5/o1F9Yhse9JlIC8HohQEGLp8b79MiYEfdA9CHyyjD M9rjaJj45fI8T17dG7BVpCEp/IAdS3trTFj2R5D0y6ljCn2B2rNmy0TpLHl10Jr+9jtz e8Fg== Received: by 10.68.226.100 with SMTP id rr4mr6750569pbc.143.1346971627858; Thu, 06 Sep 2012 15:47:07 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id hf1sm2060437pbc.42.2012.09.06.15.47.05 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 15:47:07 -0700 (PDT) Date: Thu, 6 Sep 2012 15:47:03 -0700 From: Arthur Mesh To: RW Message-ID: <20120906224703.GD89120@x96.org> References: <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120906230157.5307a21f@gumby.homeunix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 06 Sep 2012 23:13:09 +0000 Cc: freebsd-rc@freebsd.org, freebsd-security@freebsd.org, Doug Barton Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 22:47:10 -0000 On Thu, Sep 06, 2012 at 11:01:57PM +0100, RW wrote: > Reusing a secure entropy file is only a problem if the complete history > of yarrow, from boot until some significant output, is exactly the same > as on a previous boot. Not sure I agree. It's not the only problem. It's the worst problem; in the situation you describe, you'll end up with identical output from /dev/random. > Once something changes you get a completely > different sequence of yarrow cipher-keys; a counter or writing out > a new entropy file will both do this, but OTOH so will any difference in > harvested entropy such a sub-nanosecond difference in timing. You're correct. Are you arguing that we shouldn't recycle /entropy after it's used? If so, why are you okay with making life easier for active attackers? From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 23:40:48 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D9577106566B; Thu, 6 Sep 2012 23:40:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 6F88914DEB8; Thu, 6 Sep 2012 23:40:48 +0000 (UTC) Message-ID: <50493480.8060307@FreeBSD.org> Date: Thu, 06 Sep 2012 16:40:48 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Mesh References: <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> In-Reply-To: <20120906224703.GD89120@x96.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, freebsd-security@freebsd.org, RW Subject: Re: svn commit: r239569 - 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: Thu, 06 Sep 2012 23:40:48 -0000 On 9/6/2012 3:47 PM, Arthur Mesh wrote: > On Thu, Sep 06, 2012 at 11:01:57PM +0100, RW wrote: >> Reusing a secure entropy file is only a problem if the complete history >> of yarrow, from boot until some significant output, is exactly the same >> as on a previous boot. > > Not sure I agree. It's not the only problem. It's the worst problem; > in the situation you describe, you'll end up with identical output from > /dev/random. Arthur, I've asked you repeatedly to demonstrate the truth of this claim. You and David are speaking completely theoretically about a possible attack vector. I (and others) have repeatedly provided hard facts that demonstrate that what you're concerned about cannot happen, and yet you repeatedly claim it can. It is way past time that you either demonstrate that your claim has merit, or stop making it. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-security@FreeBSD.ORG Thu Sep 6 23:44:39 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id A0FAA1065674; Thu, 6 Sep 2012 23:44:39 +0000 (UTC) Date: Thu, 6 Sep 2012 16:44:38 -0700 From: David O'Brien To: Doug Barton Message-ID: <20120906234438.GA19715@dragon.NUXI.org> References: <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <50493480.8060307@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50493480.8060307@FreeBSD.org> X-Operating-System: FreeBSD 10.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , freebsd-security@freebsd.org, RW , freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:44:39 -0000 On Thu, Sep 06, 2012 at 04:40:48PM -0700, Doug Barton wrote: > Arthur, I've asked you repeatedly to demonstrate the truth of this > claim. You and David are speaking completely theoretically about a > possible attack vector. I (and others) have repeatedly provided hard > facts that demonstrate that what you're concerned about cannot happen, > and yet you repeatedly claim it can. "PROVIDED HARD FACTS"? Doug please state them again as I seem to not be seeing them. I've seen claims without be supported by literature, code, or measurements. > It is way past time that you either demonstrate that your claim has > merit, or stop making it. Ditto. -- -- David (obrien@FreeBSD.org) From owner-freebsd-security@FreeBSD.ORG Fri Sep 7 00:18:43 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EE626106564A; Fri, 7 Sep 2012 00:18:43 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B396014D9DB; Fri, 7 Sep 2012 00:18:43 +0000 (UTC) Message-ID: <50493D63.9070104@FreeBSD.org> Date: Thu, 06 Sep 2012 17:18:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: obrien@freebsd.org References: <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <50493480.8060307@FreeBSD.org> <20120906234438.GA19715@dragon.NUXI.org> In-Reply-To: <20120906234438.GA19715@dragon.NUXI.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , freebsd-security@freebsd.org, RW , freebsd-rc@freebsd.org Subject: Re: svn commit: r239569 - 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 00:18:44 -0000 On 9/6/2012 4:44 PM, David O'Brien wrote: > On Thu, Sep 06, 2012 at 04:40:48PM -0700, Doug Barton wrote: >> Arthur, I've asked you repeatedly to demonstrate the truth of this >> claim. You and David are speaking completely theoretically about a >> possible attack vector. I (and others) have repeatedly provided hard >> facts that demonstrate that what you're concerned about cannot happen, >> and yet you repeatedly claim it can. > > "PROVIDED HARD FACTS"? Doug please state them again as I seem to not be > seeing them. Yes, that's part of the problem. :) Thinking about it more, I think that you and Arthur are conflating 2 related-but-different concepts that may explain the confusion. I alluded to this in one of my previous messages, but I think it's important to make it more clear. (It's also worth noting that I'm also guilty of conflating these 2 issues in some of my responses, mea culpa.) The first thing that we want to be sure of at boot time is that we stuff a sufficient quantity of material into the pool so that the device can start providing high-quality random bits as early after boot as possible. The other thing we need to do is to be sure that we don't create a situation that will allow an attacker to determine the interior state of the device, and therefore be able to predict what "random" bits are going to be spit out by it. The latter issue _is_ important, and we did take it into account in both the kernel code and the surrounding infrastructure. But other than for super high-security systems that rely heavily on what comes out of /dev/random it's not a threat model that we spend a lot of time on because nowadays anyone in that kind of situation uses a dedicated hardware device to provide their random bits. So our primary concern is that we stuff enough things into the device early so that it will start spitting out "good" "random" bits ASAP. By default, all of the hardware harvesting is on when the device is first loaded by the kernel. So long before we even get to the rc.d parts of the system the internal state of the PRNG is *already* unpredictable (where the definition of "unpredictable" is conditioned by the threat model described above). When we reach the initrandom point in the process, we add a little more entropy with the "better than nothing" commands, and the contents of /entropy. At that point we have already reduced the possibility of an attacker being able to guess the internal state of the device to a statistically insignificant number for any practical threat model that a FreeBSD system is likely to face. Anyone who still doesn't feel that's enough would want a hardware device anyway. So the only remaining problem is to continue to stuff the highest quality entropy we can into the pool to improve the device's ability to spit out high-quality pseudo-random bits. I do think that you and Arthur have raised an interesting issue by pointing out that the way we have been using the stuff in /var/db/entropy could be improved. I think that my suggestion of "randomizing" the order in which we start using those files addresses both making it harder for an attacker to guess the internal state, and my concern about not discarding useful material in the event of a fast reboot. I also think that my suggestion of adding a new entropy file to /var/db/entropy at boot time (instead of replacing /entropy) helps address the concern you and Arthur raised about making it harder for an attacker to guess the internal state. In other words, I have listened to what you both have said, and tried to make suggestions that address your concerns without completely gutting the existing system. >> It is way past time that you either demonstrate that your claim has >> merit, or stop making it. > > Ditto. David, you and Arthur are the ones making claims that radical changes are necessary to a system that has stood the tests of time for 12 years. You need to prove the claims you're making about the deficiency of the system prior to your changes. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) 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= From owner-freebsd-security@FreeBSD.ORG Fri Sep 7 01:52:17 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 9C5D6106564A; Fri, 7 Sep 2012 01:52:17 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4575A8FC0A; Fri, 7 Sep 2012 01:52:16 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q871q356076012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Sep 2012 11:52:04 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q871pvVa033740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 11:51:58 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q871pvXm033739; Fri, 7 Sep 2012 11:51:57 +1000 (EST) (envelope-from peter) Date: Fri, 7 Sep 2012 11:51:57 +1000 From: Peter Jeremy To: freebsd-security@freebsd.org, freebsd-rc@freebsd.org Message-ID: <20120907015157.GA29497@server.rulingia.com> References: <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20120906224703.GD89120@x96.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arthur Mesh , Doug Barton , RW , Xin Li Subject: Re: svn commit: r239569 - 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:52:17 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Sep-06 12:17:40 -0700, Xin Li wrote: >On 09/06/12 11:21, David O'Brien wrote: >> At this point I am liking: sysctl kern.cp_times kern.cp_time >> kern.lastpid kern.timecounter \ kern.tty_nout kern.tty_nin vm vfs >> debug dev.cpu \ | tr -Cd '0123456789xabcdef' > >I think you could use sysctl -n to remove the variable names (which is >a good thing). That seems reasonable. > I'm a little bit concerned with the fact that most of >the characters here are numbers, would it be a good idea to filter it >with e.g. gzip (my $.02) by the way before feeding into /dev/random? Given that /dev/random can only cope with 4KB/write and 10 writes/sec before it starts discarding input, some sort of compression function is worthwhile. My gut feeling is that gzip won't lose entropy, though a hashing function could. I've done some experiments on a couple of systems to look at gzip and sha256 speed. On one box, "sysctl -an" returns 109989 bytes (though it has been up for a while) which gzip's to 12511 bytes (still too large for a single write to /dev/random). The following is the wallclock time to run sha256 or gzip on that input (based on multiple runs of 100 loops). sha256 gzip -6 CPU 3.3ms 5.9ms 2.5GHz amd64 (Athlon 4850e) 6.8ms 13.3ms 1.6GHz i386 (Atom N270) 85 ms 34 ms 700MHz ARMv6 (Raspberry PI, running Linux) These times are all in the noise compared to overall startup time. On 2012-Sep-06 15:47:03 -0700, Arthur Mesh wrote: >On Thu, Sep 06, 2012 at 11:01:57PM +0100, RW wrote: >> Reusing a secure entropy file is only a problem if the complete history >> of yarrow, from boot until some significant output, is exactly the same >> as on a previous boot. > >Not sure I agree. It's not the only problem. It's the worst problem; >in the situation you describe, you'll end up with identical output from >/dev/random. I don't believe this is possible in practice for two reasons: 1) Yarrow starts collecting entropy from hardware devices as soon as it initialises. It will already have some entropy before init(8) is started and will be gathering more as rc scripts run. 2) Inputs to /dev/random are tagged with a high-resolution timestamp. I don't believe this runs at less than 1MHz on any platform and will typically run at >>100MHz. In order to reproduce the state, you need to feed the same input in with sub-microsecond timing. And this all occurs well before user logins are allowed. If you have an attacker that can tightly control what happens during early system startup, you have more serious problems than the amount of entropy in /dev/random. --=20 Peter Jeremy --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBJUz0ACgkQ/opHv/APuIcgIwCgvlNkCyioy7uOYrM+kM6PVLCz kKkAniqCPanegQiytiBiV2Cs70f1eY9n =0+Aa -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-security@FreeBSD.ORG Fri Sep 7 08:53:48 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 8AE89106566B; Fri, 7 Sep 2012 08:53:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 458DE8FC16; Fri, 7 Sep 2012 08:53:47 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 018BD65FC; Fri, 7 Sep 2012 10:53:47 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id C341E832F; Fri, 7 Sep 2012 10:53:46 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org> <20120906164514.GA14757@dragon.NUXI.org> <867gs7qcsl.fsf@ds4.des.no> <20120906184400.GF13179@dragon.NUXI.org> <86lignot6a.fsf@ds4.des.no> <20120906200325.GA17159@dragon.NUXI.org> Date: Fri, 07 Sep 2012 10:53:46 +0200 In-Reply-To: <20120906200325.GA17159@dragon.NUXI.org> (David O'Brien's message of "Thu, 6 Sep 2012 13:03:25 -0700") Message-ID: <86harap61x.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-security@FreeBSD.org, Doug Barton , freebsd-rc@FreeBSD.org, Mark Murray 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 08:53:48 -0000 David O'Brien writes: > I am not sure what you are arguing. Are you asking for 'kenv' to be > removed from better_than_nothing() ? Or are you just making sure folks > are aware it is not a source of strong entropy? I am arguing against your claim that kenv is better than ps. Even if it does vary from machine to machine, it is constant across reboots on the same machine. > We already have an invocation of 'ps'. Please suggest a *different* > command invocation. ps -axo majflt,minflt,nivcsw,nvcsw DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Sep 7 13:27:50 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 115B9106566C; Fri, 7 Sep 2012 13:27:50 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE2C8FC18; Fri, 7 Sep 2012 13:27:48 +0000 (UTC) Received: by eeke52 with SMTP id e52so1325708eek.13 for ; Fri, 07 Sep 2012 06:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=O3Xr9SEX3C4C85FaIli6eQLVnwJgFCQ+3RExdMQOh5k=; b=K7uxAQxHPvwLDv8tgE5Krn6AIpEvev9eDdcDjrVWt52DLYegbU3nSsMrC/iQzFxgf4 qXi2RIlkBQzmCH8xRaoTPtRNKidSvrU7kuW6BtXIlyro/vGJSMS/0w8trwOTw0j3Rr6J iaB2p4rtFK3KBR6rqhE9xARITpw75k6FfYOld0rDmmr81wHLOgfhvEIn/z63fQKQ24ke YXchOvS+MfGQC8ZJ/iLFaI5+M9xSLGUT2R2ob9lUsQ46UrMEZ2legIAMpB8rs0uD1pSD msb8mkvpVSPSopdCyMAFD0C3MXmdAkr8LFF/c4ZdJdW9+096EHuN1wimGGT/i+B1kntm yUAA== Received: by 10.14.204.72 with SMTP id g48mr7932692eeo.45.1347024468292; Fri, 07 Sep 2012 06:27:48 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id e42sm12763822eem.8.2012.09.07.06.27.46 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 06:27:47 -0700 (PDT) Date: Fri, 7 Sep 2012 14:27:42 +0100 From: RW To: Arthur Mesh Message-ID: <20120907142742.5436e72a@gumby.homeunix.com> In-Reply-To: <20120906224703.GD89120@x96.org> References: <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, freebsd-security@freebsd.org, Doug Barton Subject: Re: svn commit: r239569 - 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 13:27:50 -0000 On Thu, 6 Sep 2012 15:47:03 -0700 Arthur Mesh wrote: > > Once something changes you get a completely > > different sequence of yarrow cipher-keys; a counter or writing out > > a new entropy file will both do this, but OTOH so will any > > difference in harvested entropy such a sub-nanosecond difference in > > timing. > > You're correct. Are you arguing that we shouldn't recycle /entropy > after it's used? No, I was pointing out that a counter does make a difference because it *unconditionally* allows yarrow to continue working as a secure PRNG across reboots with the same secure entropy file. Replacing the entropy file is desirable if you are concerned that an attacker might gain access to it and try to reconstruct the early state of yarrow. I don't regard that as a particularly serious threat, anyone that gains root or physical access will have better things to do. I'm not averse to rewriting /entropy provided that you can guarantee that that the entropy has made it into the yarrow entropy pools and the subsequent slow reseed has completed before the new file is written out. Overwriting an entropy file that secures yarrow against remote attacks with one that might not would be a retrograde step.