Date: Fri, 21 Nov 2014 11:57:46 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Mark R V Murray <mark@grondar.org> Cc: arch@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, Adrian Chadd <adrian@freebsd.org> Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <1416596266.1147.290.camel@revolution.hippie.lan> In-Reply-To: <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <AE8F2D30-7F91-4C90-B79A-D99857D8AED8@grondar.org> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2014-11-21 at 18:45 +0000, Mark R V Murray wrote: > > On 21 Nov 2014, at 15:16, Ian Lepore <ian@FreeBSD.org> wrote: > >=20 > >> If you can demonstrate a usable system w/o much modifications that > >> runs w/ the dummy interface, or no boot random, that I'll drop my > >> suggestion... I'll try removing random tomorrow and see what breaks= ... > >>=20 > >=20 > > If your point is that after the recent commits you can no longer do > > these things, then I guess that's kind of hard to argue with given th= at > > some of us have been trying to say for a couple years that if=20 > > /dev/random starts blocking to wait for entropy at startup, existing > > *functional* small systems will stop working. >=20 > As a fair bit of the security subsystem depends on working /dev/random, > this is true. >=20 > HOWEVER - I=A2m most willing to entertain ideas on how to get a general > config going that disables anything that is /dev/random-dependant. >=20 > Asking the SO to break sshd(8) isn=A2t going to work, but enabling > (say) telnet and/or rsh in the !random(4) case could be a way to do > it. >=20 > > Before those changes everything worked fine on the 90mhz 64MB arm > > systems we build products around, which have no more than a few bits = of > > entropy available during the boot process, and which (I'll say it aga= in > > even though nobody has ever paid any attention to it) don't actually > > need any entropy to come up and do what it is they are designed to do. > >=20 > > They don't use https (a few of them don't even have network > > connections). They use ssh for its convenience (it's better than > > telnet), but NOT for security. (And really, whether that makes sense= to > > you or not, "the system must be secure" is not your decision to make.= ) >=20 > Why not just use rsh? If the security overhead is onerous, don=A2t use = it. >=20 > > I haven't tested a recent -current on those small systems, but we've > > already resigned ourselves to sticking with 8.x for those older board= s > > just because the tide of bloat (both code and policy) is too much to > > swim against. >=20 > Yet you use ssh? >=20 > M All I've ever asked for, since day one of discussing this topic, is a knob to prevent /dev/random from blocking, ever. A way in which an administrativive policy decision can be made about what consitutes "good enough" entropy (and by extension, security). The knob could be of the nature that it's hard to turn on accidentally -- it's a dangerous thing and like an industrial stamping press maybe you have to hold down two buttons far apart from each other to make it go. As far as I know we have that now, but it sounds like not forever. I'm just arguing in favor of providing the tools, making it reasonably hard to accidentally cut yourself on them, but ultimately leaving the policy decisions of how to use them to the people who own and run the systems. I kind of thought that was the unix way. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1416596266.1147.290.camel>