From owner-freebsd-security Thu Apr 16 04:20:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA12419 for freebsd-security-outgoing; Thu, 16 Apr 1998 04:20:24 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12408; Thu, 16 Apr 1998 04:20:19 -0700 (PDT) (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.8.8/8.8.8) with ESMTP id EAA24061; Thu, 16 Apr 1998 04:19:58 -0700 (PDT) (envelope-from tweten@ns.frihet.com) Message-Id: <199804161119.EAA24061@ns.frihet.com> X-Mailer: exmh version 2.0.2 2/24/98 Reply-to: tweten@frihet.com To: dima@best.net Cc: tsprad@set.spradley.tmi.net (Ted Spradley), louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions From: "David E. Tweten" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Apr 1998 04:19:58 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk dima@best.net said: >Normal users *do not need* to have an read acces to the kernel. >They simply don't. I'm sorry, but this one finally pinched my corn. System administrators who believe users must prove that they need a service or resource before they will be permitted access to it have always annoyed me. When they get the upper hand, such administrators destroy user productivity by forcing the more numerous class of "users" to waste time proving when they should be using. When I have the opportunity, I try to challenge such *administrators* to prove that no users have a need before clamping down. "Prove to my you need it" is not the Unix way as I understand it. To quote from the forward of the original Bell System Technical Journal introducing Unix [volume 57, number 6, part 2], "He [Ken Thompson] and the others who soon joined him had one overriding objective: to create a computing environment where they themselves could comfortably and effectively pursue their own work ..." What resulted was a system that presumed openness, and restricted users only when there was a compelling need to do so. So, my challenge to you is, "Show me how the current kernel permissions can be used to crack FreeBSD." If you can't, please don't restrict them. If you must, please put mention of this change on a readme file list of gratuitous restrictions, so I can remove it from my systems without losing too much sleep over why it was there in the first place. -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message