is this wise?

[John Chambers]

In article <53862 at uunet.UU.NET>, rick at uunet.UU.NET (Rick Adams) writes:
> > wrong with the open() call we have already?
> 
> You don't use the open() call because it doesnt fit well conceptually.
> Why not force EVERYTHING to use open().  I can see it now:
> 	getpwuid(213) becomes open("/dev/password/213")
> 	gettimeofday() becomes open("/dev/clock")
> 	etc.
> By your argument, we change everything to use open. (And if you
> think the kernel is big now, wait until you move most of the
> userlevel networking code into it)

These are silly, perhaps, but there's a reasonable argument for a version
of Unix that uses open() much more widely.  Imagine yourself trying to do
a security analysis of your kernel.  In earlier days, the only way a process
could gain access to anything that contains data was by calling open() or
exec(), and these both passed the name to namei().  This gave you a single
point at which all access permissions were checked.

Today, it's not so easy.  You also have to examine socket(), shmget(),
msgget(), semget(), and so on.  Each is a separate namespace for some
mechanism that accesses data, and each must be handled separately from
the others.  Each has different rules for access control.  This makes
the job much more difficult.  A building with only one door is easier
to secure than one with one door, four windows, a loading dock, and a
chimney.

It's not at all out of line to consider using ordinary file access-control
mechanisms for such things as shared-memory segments, semaphores, or TCP
sockets.  Thus, it'd be handy to be able to temporarily restrict, say,
telnet access to a system via a command like:
	chmod o-rw /dev/network/foo.bar/tcp/telnet
and have the presumably distributed version of namei() send a message to
a network server on foo.bar saying who I am and what I'm asking it to do.
>From a user's viewpoint, this would certainly be convenient, since it is
the old, familiar way of doing things.  From a security analysts' viewpoint,
it would be a big win, since it invokes a common path through a network
access-control mechanism.

With the growth of such things as distributed banking, and the adoption 
of Unix as the industry-standard OS, security issues are becoming quite
an important issue.  Unfortunately, Unix is also growing into the sort
of security snafu that we see in other commercial OSs.  With a bit of
thought, we *could* have a version of Unix that has only a single path
for all access checks.

But I suppose this is too much to hope for.  It's not nearly complicated
enough for a real-world, commercial OS.  Sigh.


-- 
John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]