From owner-freebsd-security  Thu Apr 16 20:40:52 1998
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id UAA04831
          for freebsd-security-outgoing; Thu, 16 Apr 1998 20:40:52 -0700 (PDT)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA04797;
          Fri, 17 Apr 1998 03:40:37 GMT
          (envelope-from dima@burka.rdy.com)
Received: by burka.rdy.com id UAA12029;
  (8.8.8/RDY) Thu, 16 Apr 1998 20:40:22 -0700 (PDT)
Message-Id: <199804170340.UAA12029@burka.rdy.com>
Subject: Re: kernel permissions
In-Reply-To: <E0yQ0zz-000653-00@set.spradley.tmi.net> from Ted Spradley at "Apr 16, 98 09:35:31 pm"
To: tsprad@set.spradley.tmi.net (Ted Spradley)
Date: Thu, 16 Apr 1998 20:40:22 -0700 (PDT)
Cc: dima@best.net, tweten@frihet.com, louie@TransSys.COM, trost@cloud.rain.com,
        stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG
X-Class: Fast
Organization: HackerDome
Reply-To: dima@best.net
From: dima@best.net (Dima Ruban)
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk

Ted Spradley writes:
> > Ted Spradley writes:
> > > > 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.
> > 
> > How can I prove that there's nothing else they can get from reading my kernel,
> > if I'm trying to prove opposite?
> 
> You have to prove that there is nothing else besides attempting to hack 
> your machine that these users could possibly get from reading the kernel. 
>  That is, you have to prove your assertion that there is nothing useful 
> that users could get from reading the kernel.

Ahh, sorry. It was probably problem with my English.
Okay. What can user get from being able to read kernel.

1. Debugging symbols and symbol table		- user doesn't need that.
2. Possible kernel configuration		- questionable.
3. Kernel namelist				- user doesn't need that.
4. Kernel copy with possible commercial stuff	- user doesn't need that.
5. Kernel copy with possible restricted/crypto	- user doesn't need that.
   stuff.

I believe, this is about it, or at least I can't think of anything else.
Everything else user can get using standard commands. All of
such a commands have sgid on kmem. (This includes 
netstat/dmesg/systat/nfsstat/w/ps/etc, etc, etc.)

> 
> I just wanted to clarify my wording.  I've had quite enough of this subject.  We've already wasted far more effort on the discussion than I was attempting to save by preventing a gratuitous change.
> 

Me too. Honestly, I didn't expect any objections on this subject and
was quite surprised after receiving so much responces (mostly from you :-)

> 

-- dima

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