Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Apr 1998 14:06:30 -0700 (PDT)
From:      dima@best.net (Dima Ruban)
To:        tweten@frihet.com
Cc:        dima@best.net, tsprad@set.spradley.tmi.net, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG
Subject:   Re: kernel permissions
Message-ID:  <199804162106.OAA09190@burka.rdy.com>
In-Reply-To: <199804161119.EAA24061@ns.frihet.com> from "David E. Tweten" at "Apr 16, 98 04:19:58 am"

next in thread | previous in thread | raw e-mail | index | archive | help
David E. Tweten writes:
> 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.

Excuse me? What are they (users) going to do with kernel name list
besides attempting to hack your machine?
They can't really use it anyway.


> "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 

This is totally wrong. If we will be closing only a security *holes*,
we won't go anywhere. Thre's such a thing called *potential* problem.
This one was one of potential problems as well.

> 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.
> 
> 

-- dima

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804162106.OAA09190>