Date: Thu, 16 Apr 1998 17:21:06 -0500 From: Ted Spradley <tsprad@set.spradley.tmi.net> To: dima@best.net Cc: tweten@frihet.com, louie@TransSys.COM, trost@cloud.rain.com, stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Message-ID: <E0yPx1m-0005qz-00@set.spradley.tmi.net> In-Reply-To: Your message of "Thu, 16 Apr 1998 14:06:30 PDT." <199804162106.OAA09190@burka.rdy.com>
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? No, you've missed Mr. Tweten's point. You don't get to ask. *You* have to prove that there's *nothing* else they could get from reading the kernel. Furthermore, it's not obvious to me what they could get from reading it that would allow them to "hack your machine". > They can't really use it anyway. It would be a nuisance to me if I had to su root to do the "strings /kernel | grep '^___' " thing. If you have such an adversarial relationship with these 'users' then by all means, change your file permissions on your system any way you like, but don't impose your changes on the rest of us. BTW, you can make your system more secure by disconnecting the network cable, and even more secure by disconnecting the power cable. > > "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 > 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?E0yPx1m-0005qz-00>