NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/20208

Internet Message Format | 1993-01-02 | 13.7 KB

Path: sparky!uunet!cis.ohio-state.edu!ucbvax!lrw.com!leichter
From: [e-mail] (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: re: Re: HELP!!! Security problem for gurus. [Directories]
Message-ID: <[e-mail]>
Date: 2 Jan 93 12:35:06 GMT
Sender: [e-mail]
Distribution: world
Organization: The Internet
Lines: 268


    >[I wrote:]
    >    One of the fields shown was "TYPE" at offset 4.  [...] it had
    >    the exact same value [...] for ALL directory entries in ALL
    >    .DIR files.  I wondered what OTHER valid values for that field
    >    existed [...]
    >
    >Interesting.  The ODS-II specs, as best I can recall, define two
    >possible entry types:  Files and links.  Files are what you would
    >expect. A link is a like a Unix "soft link":  A text string that
    >replaces the file specification being parsed.  While specified way
    >back when ODS-II was first designed (i.e., when VMS was designed),
    >this feature has never been implemented.

    [Chris Chiesa responds:]
    Being unfamiliar as I am with the specific behavior of "a Unix 'soft
    link'," can you elaborate on the intended behavior of this
    interesting-sounding never-implemented feature?  I'm just wondering
    what we're missing out on.

A Unix soft link (also known as a symbolic link, or symlink for short) is
similar to a logical name embedded in the file system.  For example, if entry
/u1/leichter/file were a link to /u2/chiesa/other_file, then when someone
attempted to read /u1/leichter/file, when Unix got to the link it would throw
out the file name it had so far and start again with the other file,
/u2/chiesa/other_file.  That name might resolve to a file, to another link, or
to nothing at all.  But assuming that other_file actually exists, the link
would provide me with a way to refer to a file in your directory indirectly.
(If my default directory were /u1/leichter, then I would only have to mention
the spec "file" to get to the link.)

This kind of link would be easily interpretable in a VMS environment:  If the
link is a fully specified file (device, directory, etc.), then it simply
replaces the original specification.  (There are still some interesting
complications as to how this should interact with RMS filename parsing,
especially how it should be used for "sticky defaults" applied to later files;
but in this simple case the solutions are pretty simple.)

More generally, we have to decide what to do if the link is NOT a fully
specified name.  For example, suppose by current directory is /u1/leichter,
and I refer to /u1/leichter/subdir/link, which is a link to somefile.  What
directory should we search for "somefile" in?  If we simply replace the entire
spec, we effectively look in the current default directory.  If we replace
only the last element of the spec, we look in the same directory link was
found in.  (I.e., we either get just "somefile", to which the default
directory is applied, or /u1/leichter/subdir/somefile.)  Unix takes the second
interpretation:  Interpret relative to the directory in which the link is
found.  However, it does this even though it really replaces the entire spec.
The reason for this peculiar state of affairs has to do with links to
directory.  The actual rule is:  If, while interpreting any element of a spec,
you encounter a link, throw out everything in the spec up to this point,
insert the link value, then stick back the rest of the spec.  Now, temporarily
using the directory in which the link was found as the default directory,
interpret the resulting spec.

Thus, if /chiesa/ld is a link to local_directory, then a reference to

        /chiesa/ld/sources/v2/foo.c

will be resolved to

        local_directory/sources/v2/foo.c

relative to /chiesa, or

        /chiesa/local_directory/sources/v2/foo.c

How should this work on VMS?  It's not at all obvious, given the more complex
syntax of VMS file specifications - and, much more to the point, the existing
complex semantics of VMS file name parsing.  It would all have to be worked
out in a useful way.  It never has been.

    >(ODS-II has several other "spec'ed but never implemented" features,
    >including a hashed file type and something I gather will finally
    >appear in VMS V6: Access-mode restricted files (i.e., files that can
    >only be accessed from inner-mode code, regardless of the usual
    >protections on the file).

    Very interesting!  What's a "hashed" file type?  Again, can you
    elaborate?

The documentation doesn't say, but from context (and from knowing what was
going on in the field at the time the spec was written), it was almost
certainly intended to describe a file structure which used hashed index
tables, rather than the B*-trees of RMS indexed files.

            This may be a loaded question, but: how does it happen
    that features can  BE "spec'd but never implemented?"

The spec gets written before the code, you know - quite some time before.
It's also written for rather different purposes.  The ODS-II spec was written
to describe a very general new file system to replace ODS-I, the RSX file
system.  It's common for the architect to specify things that look as if they
might soon be needed.  Sometimes he's right; sometimes he's wrong.

                                   What determines
    whether a particular feature gets implemented right away, or after a
    long delay (how long has ODS-II been in existence with
    spec'ed-but-never-implemented features?), or never?

ODS-II pre-dates VMS.  What decides when or if features get implemented is
complex and tough to pin down.  Theoretically, product management specifies
features based on customer demand.  While this MIGHT happen in the new,
reformed DEC, in practice the reality is fairly chaotic, with features being
decided on by a mix of product managers, various other levels of managers -
and ultimately the implementors, who can effectively veto things by making
very high cost estimates, or add things by just doing them.  A famous example
is the reverse-video "Interrupt" you get for CTRL/Y.  This started out as a
joke played on the VMS group by the terminal driver implementor:  He snuck it
in one day.  Everyone liked it, so it ended up in the product.

                                 And, finally, how
    do YOU find out about these things, Jerry?

That would be telling.

                            Inquiring minds... etc.
    ;-)

Seriously, I have a copy of the ODS-II spec - after all, I *did* work for DEC
for 12 years!  It's not a particularly secret spec; I know other people have
copies, probably more recent ones than mine.

    >I believe DIRECTORY accesses the directory files directly, rather
    >than going through RMS.  It probably doesn't check the validity of
    >the entries it sees.

    It seems evident from what I've observed, that DIRECTORY doesn't
    (currently)  validate at least the contents of the "type" field I
    played with -- but I'm afraid I don't see how it makes any difference
    whether one "accesses the directory files directly" OR "(goes) through
    RMS."  If I open "filespec.DIR" as a FILE, I can read it just fine
    using RMS -or- "directly."  Do I misunderstand you, Jerry?

No; that's just what I mean.  The SUPPORTED access to .DIR files is through
RMS, which is the component of VMS that maintains them.  The $SEARCH service
lets you wild-card through a directory; if you or I wanted to write a replace-
ment for DIRECTORY, $SEARCH would be the supported way for us to do it.  I
believe, however, the DIRECTORY simply reads the .DIR file as a file.  Sure,
that might (or might not) go through RMS; actually, it might be simplest to
simply map the directory into memory as a disk section.  But even if it went
through RMS, it would be as a normal file, not as a directory; RMS would not
be trying to interpret the records as directory entries.

    >Just out of curiosity (since you've done this already), did DIRECTORY
    >work when you were looking at more than just the file spec?  (Every
    >other field - well, every other field except the file id - requires
    >access to the file's header.  Did DIRECTORY manage to access the
    >header?)

    Ehhhhhh...  I'm afraid you've caught me out, here, Jerry.  I did ONLY
    a "DIRECTORY" command and a "DIRECTORY filespec" command - didn't try
    /DATE or /SIZE or any of the file-header-access-requiring qualifiers.
    I'll try this and get back to this thread, if someone else doesn't
    beat me to it as seems highly probable.

Well, no one has yet!

    >    I expect that this technique--
    >
    >     [...]
    >
    >      c) would stymie any system manager, probably any CSC
    >         representative, who hasn't read this post just now,
    >    regardless of privs;
    >
    >Actually, I have serious doubts about c.  ANALYZE/DISK is pretty
    >certain to check directory entries for validity.  Your munged entries
    >will stand out like a sore thumb.  It's a good bet that
    >ANALYZE/DISK/REPAIR would fix the invalid entries by removing them
    >and then later noticing the files involved are lost and moving them
    >to [SYSLOST].

    Didn't think of that.

That's how people get caught!  :-)  It's VERY hard to think of everything....

                   I can count the number of times I've done an
    ANALYZE/DISK in my six-year VMS career (four of them as a system
    manager of a very small system) on the fingers of one hand, and I
    don't think  I've EVER used /REPAIR...

I'm surprised.  You might want to try it - you'll probably recover some space.
Almost every disk that's been in use for a while has some lost files on it
SOMEWHERE....

    >If you want to hack with directory entries, there are plenty of other
    >things you could do.

    Some very interesting ideas, Jerry -- thanks!  I'll have to do some
    "playing!" (Yeah, it WILL probably require me to use ANALYZE/DISK
    again afterwards,  and maybe /REPAIR for the first time ;-) )

    > [...] you are safe only as long as the
    >file isn't noticed.

    Ah, that's the bottom line, isn't it...  Sometimes the best place to
    hide something is right out in plain sight... "The Purloined Letter"
    taught us that, a long time ago... ;-)

Actually, the VMS file system, and security system in general, was DESIGNED to
make it hard to hide things.  That's part of good security design.  For
example, on RSTS you could (if privileged) mark any executable file as
"privileged"; it would then run as a privileged program.  (This is similar to
the Unix setuid bit.)  What this means is that, if I can momentarily get
privileges, I can hid a program that will regain those privileges anywhere
at all on the disk, under any innocent name I like.  If you let me remove a
disk from the system and later put it back, I can take it to another system
which lets me "diddle the bits" on the disk and do the same.  Finding my
hidden privileged program would be a pain in the neck.  It can remain hidden
on the disk for years, waiting for me to exploit it.

In VMS, on the other hand, the only way to make a program privileged is to
INSTALL it.  To get my own file installed as privileged, I'd have to edit one
of a small number of known command files (or modify an existing program that
is already installed privileged).  Both of these are much harder to do, and
much easier to find, than marking some innocuous file.  (Of course, there are
other, more subtle things I could do - but let's not go into that here.)

    >BTW, it's not impossible that SOME invalid directory entries will
    >could cause (probably non-fatal) bugchecks.

    I remember seeing RMS bugs in the past that would delete the erring
    process upon encountering certain errors in on-disk or file structure.
    I was always surprised to find such dramatic bugs in RMS, an otherwise
    extremely robust-seeming entity...

Well, nothing's perfect.  RMS is a rather complicated piece of code.

    >Also, the future direction of VMS seems to be to forbid direct access
    >to directory files (at least direct write access).  You could find
    >your modified directory entries completely inaccessible after the
    the next upgrade!

    That's VERY interesting!  At what level of the system would this be
    implemented?  Disk driver (mark certain media blocks /NOWRITE)?
    $QIO-ACP interface ("don't allow access to any file whose "I'm a
    directory" bit is set")?  Write-Logical-(or-Physical)-Block $QIO
    request?  Blocking directory-write access at any level would pose
    difficulties and paradoxes.  For example, RMS needs to be able to
    update directories, which would seem to preclude blocking
    directory-writing at the driver or $QIO levels, but NOT blocking such
    access at those levels would hardly prevent "illegal" modifications in
    the intended manner, as simply bypassing RMS would be sufficient...
    Ah well, some combination of access-mode and file-attribute check
    could be applied that would at least make "illegal" modification MORE
    DIFFICULT  than it is today.

The easiest way to do it would be to create directories with an access-mode
restriction allowing access only from executive (or kernel) modes.  When you
get down to the bottom level, the only way to access a file is through a
channel, and channels have associated access levels.  The rule for access-mode
restricted files would be that the mode of the channel must be at least as
privileged as the mode of the file.  User-mode code can only create user-mode
channels, so would not be able to get to a directory file directly.  This
might be enforced by the driver, or I suppose the concept of access-mode
restrictions might be extended to cover all devices, in which case it would
be enforced by the I/O system in conjunction with the disk drivers.

RMS, running in executive mode, would have no trouble assigning an exec-mode
channel to get to the directory file - in fact, it generally does that now.
(Actually, the only change necessary would be for RMS to also check the access
mode restriction on the file against the access mode of its caller, since RMS
always opens exec-mode channels for files it is accessing for outer modes to
prevent them from screwing around with files it is working on.  The UFO option
(User File Open) gets around this....)
                            -- Jerry