From: utzoo!decvax!harpo!seismo!hao!hplabs!sri-unix!MCB@Mit-Mc
Newsgroups: net.unix-wizards
Title: Re: protecting kmem because someone felt obnoxious.
Article-I.D.: sri-unix.4940
Posted: Tue Dec 28 02:19:40 1982
Received: Wed Dec 29 02:30:47 1982

From: Michael A Bloom <MCB@Mit-Mc>
Date: 18 December 1982 08:00-EST

While it is true that protecting kmem would be a solution to the
security problem demonstrated by the raw queue monitoring program, I
don't think it is a good one.  An awful lot of programs are written by
people who dont have root access that obtain information by reading
kmem.  Chances are that they might not have been written without free
read access to kmem.  Unfortunately, there are programs that make
people "collectors" as well.  Rehmi intimates a partial solution,
although he did not come right out and say it: modify getpass() so
that it sets raw input mode when it turns echo off. According to what
he says, you wont be able to get reliable data from reading the input
queue then... Or perhaps modify the memory driver so that certain
areas were inaccessible.  Or maybe break up kmem into two or more
files, each of which can have separate protections.

Then there are sites that dont have the "get number of chars to be read"
ioctl.  The only alternate way I know of to test for pending input is to
seek to the raw clist for your terminal and read the character count field.
There are many applications where knowing the number of characters that
are available to read is of great importance.  One of these, for example,
is the  "incremental redisplay" of many text editors including Emacs.

I dont think protecting kmem is the right idea.  Now that UNIX is becoming
so commercialized, and Bell is developing a UNIX Validation Suite to
test UNIX implementations against,  there may be the tendency for large
companies new to the UNIX field to want "secure systems".  Let them have
their secure systems,  if neccessary,  but lets at least put some thinking
into how UNIX is made secure.  Remember, kmem was _designed_ to be readable.
Bell is going to be a lot stricter than it has been on what is called
UNIX and what is not.  It could turn out that the open, easy to program
in environments that we call UNIX now wont fit the Bell model of UNIX
ten years from now if it stems from changes that arose out of panic
over security.

(
Besides which, security breaches seem to occur more on the less
comfortable to use, less open systems. For example, at Cal. State
Northridge, we have had absolutely no security problems on our UNIX
system, yet we have had a myriad of problems with our systems that run
RSTS.  Despite having gone to jail for computer crimes, a local high
school kid is still breaking in to the system and damaging the file
system or doing more serious mischief.  The dec operating system seem
to attract these types like flies, yet they have caused us no problems
on UNIX.  This is, I believe, because the people who cause security
problems do so for the challenge mostly (There are a lot more in this
class than the computer embezzlers, etc) and really dont care to
on systems that allow freedom without requiring privilege.
)