NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/vms/21834

Internet Message Format | 1993-01-24 | 3.5 KB

Path: sparky!uunet!spool.mu.edu!agate!ucbvax!galaxy.dnet!gleeve
From: [e-mail]
Newsgroups: comp.os.vms
Subject: re: granting AUTHORIZE access
Message-ID: <[e-mail]>
Date: 22 Jan 93 15:25:23 GMT
Sender: [e-mail]
Organization: The Internet
Lines: 61

As has been stated, once someone has access to AUTHORIZE,
they have full machine access.

There's one little thing that can be done to partially cover
the system, and that is to record such a person's sessions
so that IF they start inserting trapdoors, etc., there will
be a record of it somewhere. A number of techniques are possible:
give the person sysprv but set his login (from sylogin.com) to
run a "silent" version of photo and FREQUENTLY copy the log
files created by this somewhere offline so if he does give
himself all privs, he can't delete the offline copy. Recording
the session using such tools as supervisor series (perhaps
again started by sylogin when the person logs in) is another
option. Of course (plug) there exist commercial tools that do
this kind of thing; Raxco's AUDIT program does a very nice
job, and is acquiring the ability to store logs on a (cryptographically
guarded) write-once disk, so that as long as your victim doesn't
know the encrypt password, he'll leave a trail he can't avoid.

Backing up a bit, before any such audits can be used, it is essential
that there be a policy in place. The manager who wants this outside
sysuaf access must agree that certain things are verboten and
will be punished, and agree to the logging and to take at least
some of the blame if problems occur. It could help that to the
extent logs are trusted, they may also show a lack of malicious
behavior where such occurs. "May" in this case is to be seriously
considered: one can pre-arrange to do nefarious things that are
started by some command file. A very sophisticated person can
make his console sessions look clean but do all sorts of tricks.
If this is a normal corporate auditor, though, he may lack that
sophistication. Remember, too, that frequent backups can tend
to preserve evidence of this sort of thing. I have a journalling
virtual disk that would be a real handy place to give the guy
sole write access to for a normal account that was not audited
by other means...but we get into a basically infinite recursion
here.

Finally, let me point out that you can use a remote virtual
disk using fddriver even on a local machine. If you give him
access by this but tell the DECnet object not to allow writes,
the disk can be privately mounted read/write, BUT will in fact
just junk any writes. Use the remote virtual disk this way and
tell him, yes, you can access sysuaf.dat via this disk which
you can privately mount (and indeed must privately mount,
as there'd be a name conflict with the real system disk otherwise).
It will appear mounted r/w, and files can be opened r/w, but
all writes will be discarded. Thus it won't matter that AUTHORIZE
wants the file open r/w...the person will have only read access.
Thus you might get away with giving "only" readall, not sysprv,
though such is still permeable to a well informed person. I'd set
up a separate acct. with enough privs to do this, and set its
login up to get the disk mounted and get the person into the
FDAn: image of sys$system automatically (and possibly define
a process logical for him for sys$system to point at the image
in super mode), letting him have a regular account for his other
stuff, lacking the privs to get to the UAF.

If any of this will fly, it might help.
Glenn
[e-mail]