mike@Brl (12/29/82)
From: Michael Muuss <mike@Brl>
Date: 24 Dec 82 0:19:15-EST (Fri)
Programs which look in /dev/kmem are about as non-portable as anything
I can imagine, and for that reason should be avoided.
Then, there is the security issue. If you let users look in /dev/kmem,
they might very well see things that were not intended for them. You
make a mockery of the UNIX file protection mechanism. Depending on what
you use your computer for, you may even have to worry about legal
implications (Privacy Act, etc).
Philosophically, I agree with the "open" system argument, but things
can only be open to a point, or the usefulness of having the computer
around is diminished. At BRL, we consider the computer an extention of
the desk, and a normal part of the workplace. We are comitted to providing
all of our ~1300 employees with {a desk, chair, phone, terminal, and
a sliver of computer}.
Most desks are unlocked. Most UNIX files are general read or read/write.
Those desks that are NOT unlocked are that way for a reason. UNIX files
that are not generally read/write are thay way for a reason too.
"We", as "systems administrators", have to take reasonable measures to
protect information which users (for whatever reason) designate as
private. Alowing people to rummage in /dev/kmem thwarts this protection.
....but I digress....
There are two sets of information in the UNIX kernel which users really
are entitled to: static configuration information (many of the
#defines from param.h, UP hardware, etc), and dynamic information
(# of users, #of procs in use, etc, etc). Rather than provide access
to /dev/kmem, our approach has been to implement an additional
sub-driver in dev/mem.c called /dev/data. This read-only device
returns static & dynamic information about the system, and is
generally readable. The format is in <data.h>, and we guarantee
that, while it may get longer, older entries will stay in place,
for compatability.
I'm not sure that this mechanism is sufficiently general that I want
to suggest that everybody do this, BUT it is a *substantial* improvement
over allowing access to /dev/kmem. It also provides us with insulation
between the user layer and kernel code. Our kernel code changes
frequently; no user process has any business knowing how things
get done. (Alas, that last statement is not true: PS and the Crash-Dump
analyzer do indeed need to know how the kernel works, and we wind
up changing them a lot to keep up with the kernel).
Best,
-Mikesmk (12/30/82)
Since I deal with computer security, I find that there are two schools of thought on computer systems: 1. Give some minimal protection. 2. Try to protect the system. However, unless all the users are trustworthy, 1. is hopeless. All you need is one obnoxious user to mess you up. When that happens, you'll be surprised how soon you want to protect everything. Solution 2 is much better but since UNIX has holes, you'll be adding security piecemeal. Even though you are safer, don't get lured into a false sense of security. Why have the protection n users and files if you can break it? Let's add security to future versions of UNIX. A quick hack (/dev/*mem) will always hurt because not much thought was given to the consequences. All interfaces to the operating system should be minimal and well-defined. /dev/kmem is not, but system calls are. Any function that is worth having should be a system call. (Remember the renice discussion?)