Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 9 Feb 2002 14:46:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 9 Feb 2002 14:46:12 -0500 Received: from smtp.cogeco.net ([216.221.81.25]:8191 "EHLO fep3.cogeco.net") by vger.kernel.org with ESMTP id ; Sat, 9 Feb 2002 14:45:57 -0500 Subject: Re: Continuing /dev/random problems with 2.4 From: "Nix N. Nix" To: Bill Davidsen Cc: Robert Love , Roland Dreier , linux-kernel@vger.kernel.org In-Reply-To: In-Reply-To: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Feb 2002 14:45:13 -0500 Message-Id: <1013283914.6628.6.camel@tux> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2002-02-06 at 11:16, Bill Davidsen wrote: > On 5 Feb 2002, Robert Love wrote: > > > On Tue, 2002-02-05 at 18:02, Bill Davidsen wrote: > > > > > You seem to equate root space with user space, which is a kernel way of > > > looking at things, particularly if you haven't been noting all the various > > > hacker attacks lately. Just because it is possible to run in user space > > > doesn't mean it's desirable to do so, and many sites don't really want > > > things running as root so they can feed other things to the kernel. > > > > > > The assumption that power users will know how to fix it and other users > > > won't notice they have no entropy isn't all that appealing to me, I want > > > Linux to be as easy to do right as the competition. > > > > It is certainly desirable to run as much as feasibly possible in > > userspace. The only exception of things that could be handled in > > userspace but are allowed to live in kernel space would be performance > > critical and stable items (say, TCP/IP). > > Given that there is graphics stuff in there, and web server stuff, I > would say that having the system hang waiting for entropy is a performance > issue. And lack of it is a security issue. > > > No one said the rngd has to run as root. For example, run it as nobody > > in a random group and give /dev/random write privileges to the random > > group. > > So a functional /dev/random would be a feature of power users installing > fixes, as opposed to the kernel using the available hardware? And having > one or more extra user space daemons crapping up the system doesn't seem > an issue? > > > If userspace equates to insecure, and we stick things in the kernel for > > that reason, we are beyond help ... > > Not all Linux users are hackers, and depending on users to know their > hardware, find, build, install, and configure something, change ownership > of a device without messing it up, and understand that not doing so is > both a performance and security issue... seems either optimistic or just > unconcerned with the users. What about distributors ? These user space daemons and device ownership changes can be done by the installation process of any given distro. I know Mandrake allows users to choose their "security level" from install. The options range from "Welcome to crackers" to "Paranoid". I'm certain that distros could perform the proper steps upon detection of, say, a RNG. > > -- > bill davidsen > CTO, TMR Associates, Inc > Doing interesting things with little computers since 1979. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/