Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!milano!uudell!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.aix
Subject: Re: Question abt /etc/crash & proc struct
Message-ID: <19395@rpp386.cactus.org>
Date: 24 Jun 91 13:21:45 GMT
References: <1991Jun19.151832.17038@socrates.umd.edu> <8633@awdprime.UUCP> <1991Jun21.151601.29883@batcomputer.tn.cornell.edu> <8693@awdprime.UUCP>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Cheeseburger in Paradise, Le Select, St Barts., FWI
Lines: 65

In article <8693@awdprime.UUCP> mbrown@testsys.austin.ibm.com (Mark Brown) writes:
>shore@theory.TC.Cornell.EDU (Melinda Shore) writes:
>>It is not at all clear what you mean by this.  If you mean that no
>>program outside the kernel should be able to access the proc table,
>>that's obviously incorrect.  If you mean that the pages containing the
>>proc table should be protected by the mmu, that's less obviously
>>incorrect, but incorrect nevertheless.
>
>[NOTE: most of what I know about the /dev/kmem aspect of system security
>vis-a-vis NCSC standards I learned by word-of-mouth. My opinions on this
>subject, therefore, are not authoritative.]
>
>Not so obvious at all, I've found.
>
>Actually, there are very valid reasons for not allowing user programs
>access to the proc table information (excepting in a very limited
>fashion). They have to do with system security and user information
>security on that system.
>
>Note, for example, that PIDs on the 6000 are assigned in a "random"
>order, to hide information that can (I've been told) be used against
>the system.
>
>Mr. Haugh knows a *lot* more about the details of these issues than I,
>and can probably be persuaded to explicate them....

Gee, thanks.  I'll remember your name next time I can find some way
to pick on you ;-)

There is no "real" reason to deny the capability in an abstract sense.
That is, there is no way to construe what the Orange book (or any other
security text for that matter) says to imply that denying access to
the proc structure to all processes is a requirement for system
security.

What the Orange book talks about is authorization to access particular
information.  Clearly "write" access must be denied - that much is
spelled out for B1 in section 3.1.3.1.1 - the system must maintain a
"domain" that is free from tampering.  Read-only access prevents
tampering, therefore.  Section 3.1.2.1 says the system must allow
access to authentication data only to accessed by authorized programs.
Setting the permission bits on the device file and putting people in
the authorized groups (or giving away set-ID privileges) would be
"authorization".

The real reasons for denying access are all "portablity" problems.
Back when I was having this argument with certain architects, their
claim was that the user would have to recompile their non-portable
programs every time the system changed and therefore allowing access
was useless.  I maintain that this argument smacks of patronization.
This is precisely what everyone does already, so IBM isn't saving
anyone any time they haven't already committed themselves to spending.

It is good that IBM provided getproc() and getuser(), and I was one
of the people pressing to have both documented - but that is not
enough.  The traditional methods for getting at the proc table must
still be supported.  There is value in being "the same", just as
there is value in being "different".  Preserving de facto standard
access methods is too important to be brushed away by a "value added"
feature.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn