Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ukma!psuvm.bitnet!cunyvm!unknown
From: rrk@byuvax.bitnet
Newsgroups: comp.os.vms
Subject: Re: Logical Names & CMU-TEK IP print spooler
Message-ID: <35rrk@byuvax.bitnet>
Date: Tue, 1-Dec-87 22:57:49 EST
Article-I.D.: byuvax.35rrk
Posted: Tue Dec  1 22:57:49 1987
Date-Received: Sun, 6-Dec-87 04:47:39 EST
Lines: 58

Your message demonstrates three things:

1. VMS $sndjbc system service must have a bug concerning concealed devices.
    I have seen it treat concealed devices correctly.  It would take some
    work on the system to determine exactly why yours isn't getting parsed
    correctly.
     
2. (Already known to me) a 28-byte structure is communicated by $sndjbc
    by which it can easily open the file without a file name.  This includes:
    (16 byte) device id, (6 byte) directory id (for removing directory entry
    on auto-delete, I guess), (6 byte) file ID.  This is used by DEC's
    symbionts, instead of file name, to open files.  THE ONLY SECURE WAY
    TO WRITE A SYMBIONT IS TO OPEN FILES BY FILE-ID.  The VMS utility routines
    manual incorrectly documents that the writer of the input routine may
    choose to open a file by either file-id or file name.  The writer may
    indeed choose to open by file name, but in so doing, he breaches the
    security of the system:

3.  The third conclusion is obvious:  CMU is using the file name to open
    the file, and hence breaches the security of your system:

If you don't believe me that your symbiont is insecure, find a directory
from which your symbiont correctly.  Create a command procedure which does
something like the following:

$ create x.x;1 sys$input
$ print/delete/q=<CMU queuename>/char=128 x.x;1
$ delete x.x;1
$ set file/enter=x.x;1 <name of file user shouldn't be able to read or delete>

Then run this from a totally non-privileged user's account.

Then from the same account, noting which job was queued by the procedure,
use
$ set que/entry=nnn/nochar <CMU queue>
to release the job.

I am just writing this off the top of my head.  If it doesn't work as given,
something similar will work and will print (or do whatever "CMU" does) AND
delete a file which the user shouldn't be able to touch.

The writer of a VMS symbiont, if he gets into torture, could theoretically
open the file by name and then check to make sure the ID fields in the NAM
block match those of the file just opened, but this is obtuse, and unnecessary,
and 10 to 1 the writer of your symbiont didn't--There is no reason to do
this.

In short, the writer of software which runs with system privilege (such
as your symbiont) should be responsible for privilege questions, although
DEC should have been more responsible for their documentation.  I've reported
the documentation problem to DEC (1-800-etc.) and they verified that it
is misdocumented, but I haven't seen new documentation fix it.  I would
talk gently to CMU (assuming the above test works) and suggest a change
in their input routine.

                                   Ray Whitmer
                                   AMMON: w