Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Submission for mod-os
Message-ID: <2832@sdcsvax.UCSD.EDU>
Date: Mon, 9-Mar-87 08:31:53 EST
Article-I.D.: sdcsvax.2832
Posted: Mon Mar  9 08:31:53 1987
Date-Received: Tue, 10-Mar-87 05:34:01 EST
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Johns Hopkins Hospital
Lines: 68
Approved: mod-os@sdcsvax.uucp

I'm hardly an expert on these things, but I thought my two cents
might be interesting to some. Anyway, the moderator can refuse to
post this if I don't say anything substantive.

In article <2819@sdcsvax.UCSD.EDU>, steve@basser.oz (Stephen Russell) writes:
> One approach is to provide no protection at all, as in the V
> kernel. Since process id's are small integers, any process can
> send to any other process. This means that any validation of the
> right of the sender to communicate with the receiver must be done
> by the receiver process. This seems to have the advantage of
> simplifying the kernel, and makes IPC faster, and protection is
> optional, depending on the paranoia of the receiver or the
> criticality of the operation requested. However, what are the
> disadvantages?

One possible disadvantage is that although a "paranoid" receiver
(one which carefully screens the pids of its incoming messages) can
ensure that no unauthorized process will receive its particular
service, it may be simple to deluge such a receiver with unauthor-
ized messages, thereby bringing it (and maybe important parts of the
system) to its figurative knees.  The sys admin would have to keep
an eye out for this kind of maliciousness.

> Many other systems rely on secure kernels, and establish more
> tightly controlled links between processes (a virtual circuit
> approach). The disadvantage seems to be the overhead of creating
> using and destroying such links.

True, this can be a significant performance disadvantage.  I am of
the opinion that if the system is not required to be "absolutely"
secure, then security should be enforced on a process-by-process
basis, as needed, using permission checking (possibly based on
pids), encryption, and/or whatever is necessary to ensure the
desired level of security.  If the entire system is required to be
secure, it makes more sense to build the security into the kernel,
whether you implement the tighter coupling or not.  I would expect
all communicating processes to take a hit under this scheme, but
you pays your money, you takes your choice...

> The system I am currently developing protects process id's by
> adding a large (64 bit) random number to the normal pid. This
> `signature' makes it much more unlikely that you can send to a
> process without permission, in the same way as provided by the
> sparseness of Amoeba's port numbers.

I assume this is the receiving process's pid you're talking about
here.. and the sending process is told the correct "virtual pid"
upon establishing a connection with the receiver?  (I'm not quite
clear on this, ).

> On a related issue, consider a process acting as an intermediary
> between a root owned process and some other server. How does the
> intermediary gain root privileges for its requests to the other
> server? That is, how does the server verify that the request from
> the intermediary is on behalf of a privileged process?

The process would have to be given sufficient privilege.  I would
probably make it setuid root (or equivalent non-UNIX idiom if
available).  If a process has to do root-type things, it might as
well run that way - I don't see the sense in having it run as any
other user.


                              ...!decvax!decuac -
Phil Kos                                          \
The Johns Hopkins Hospital    ...!seismo!mimsy  - -> !aplcen!osiris!phil
Baltimore, MD                                     /
                              ...!allegra!mimsy -