svn commit: r274739 - head/sys/mips/conf

[Ian Lepore]

On Fri, 2014-11-21 at 18:45 +0000, Mark R V Murray wrote:
> > On 21 Nov 2014, at 15:16, Ian Lepore <ian at FreeBSD.org> wrote:
> > 
> >> 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...
> >> 
> > 
> > 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 that
> > some of us have been trying to say for a couple years that if 
> > /dev/random starts blocking to wait for entropy at startup, existing
> > *functional* small systems will stop working.
> 
> As a fair bit of the security subsystem depends on working /dev/random,
> this is true.
> 
> HOWEVER - I’m most willing to entertain ideas on how to get a general
> config going that disables anything that is /dev/random-dependant.
> 
> Asking the SO to break sshd(8) isn’t going to work, but enabling
> (say) telnet and/or rsh in the !random(4) case could be a way to do
> it.
> 
> > 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 again
> > 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.
> > 
> > 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.)
> 
> Why not just use rsh? If the security overhead is onerous, don’t use it.
> 
> > 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 boards
> > just because the tide of bloat (both code and policy) is too much to
> > swim against.
> 
> Yet you use ssh?
> 
> 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