Veaudit/3000 Help

                               VEAUDIT / 3000

                                  User Manual

                                 (Version 28.)

                              Copyright (C) 1988
                             Current printing 1999


Eugene Volokh

                          Written by Eugene Volokh
                   Vice President, Research and Development


VESOFT address, phone, fax
Technical Support

                                VESOFT, Inc.
                             1135 S.  Beverly Dr.
                        Los Angeles, CA 90035-1119 USA
                             Phone (310) 282-0420
                              Fax (310) 785-9566

DISCLAIMER

The information in this document is subject to change without notice.  VESOFT,
Inc.  makes no warranty of any kind with regard to this material, including,
but not limited to, the implied warranties of MERCHANTABILITY and FITNESS FOR A
PARTICULAR PURPOSE.

VESOFT, Inc.  shall not be liable for errors contained herein or for incidental
or consequential damages in connection with the furnishing, performance or use
of this material.

(You may purchase additional copies of the manual directly from VESOFT or
VESOFT's representatives.)

This manual was formatted with PROSE, ROBELLE Consulting, Ltd.'s excellent text
formatter.  Thanks to ROBELLE for allowing us to use it.


Quick Demo of VEAUDIT ``contents
Quick Demo of VEAUDIT

To get a quick demo of the VEAUDIT report:

   1. :RUN VEAUDIT.PUB.VESOFT.
      Note: for security reasons, only SM users or MANAGER.VESOFT can run
      VEAUDIT.

   2. When it asks you to enter a selection, enter "1" to get a full report.
      (This will take some time to generate, but since you will usually run it
      overnight, that should be no problem.)

   3. When it asks you "(O)nline or (B)atch? ", enter "B" for (B)atch.

   4. When it asks you for the :STREAM scheduling parameters, enter AT=21:00 to
      run it at 9 PM (or whatever time you prefer).

   5. The output will be sent to the file REPORT.AUDITDAT.VESOFT.  The output
      will not go straight to the line printer, since you wouldn't want any
      unauthorized user (including the operator) to see it.

   6. Print out REPORT.AUDITDAT.VESOFT or browse through it online.  If you own
      MPEX, simply say

%PRINT REPORT.@.VESOFT;OUT=(VEAUDIT;DEV=LP)

   7. The report should be fairly self-explanatory (with our recommendations),
      but refer to the manual whenever necessary.


Introduction: VEAUDIT verifies your system security ``contents
Introduction: VEAUDIT verifies your system security

Whatever security system you use is only as strong as you make it.  Your
security system lets you set up passwords -- but what if you don't? MPE file
security lets you protect your data files -- but what about files that are
:RELEASEd? MPE lets you set the capabilities of each system user -- but what
about users who have been granted SM (System Manager) capability?

Unfortunately, such problems (passwordless users, unnecessarily :RELEASEd
files, widely granted SM and PM capabilities) aren't restricted just to
"non-security-conscious" or "badly-managed" sites.  You have 300 users on your
system -- can you be sure that you've never set up a user without a password?

Are you positive that sensitive capabilities (like SM, PM, and OP) are
restricted only to those few users who really need them?

Are you certain that no one (you, your staff, consultants, vendors) has ever,
say, :RESTOREd a file from a third-party vendor tape that happens to be a
:RELEASEd program file in a privileged group (which can be used as "Trojan
horse" by a security violator to get SM capability!)?

No system manager has the time to laboriously examine MPE's long LISTACCT,
LISTUSER and LISTGROUP listings to see who has what capabilities, who doesn't
have passwords, etc.  And what about more subtle problems? A user may not have
PM, but if he has write or save access to a PM group, he can get PM very easily
-- how can you tell whether such users exist?

VEAUDIT does automatically what might take you months manually -- it goes
through every file, every user, every group, every account in the system
looking for possible security flaws.  It then reports them for you in an
easy-to-read format, and gives you recommendations on what you need to do to
fix the problems.  It really is an "electronic auditor" (one with a keener eye
than most non-electronic auditors).

Although it can't catch all possible security problems, we are sure that when
you run it, you'll find dozens of glitches that -- if not discovered and fixed
-- could leave your system wide-open for a would-be security violator.

VEAUDIT is more than just a reporting tool (as the name implies); you can use
VEAUDIT to alter the system accounting structure as well as look at it, with a
set of commands which bring the same sort of power to manipulation of MPE
users, accounts and groups as MPEX brings to manipulation of MPE files.  These
commands go beyond just security needs and give you powerful system management
capabilities as well.

VEAUDIT commands let you do the following to entire sets of users, accounts and
groups:

   * Select them by various attributes (such as password, capability, access
     mask, etc.).

   * List them in one- or two-line per object format (much more convenient than
     MPE's LISTACCT/LISTUSER/LISTGROUP output).

   * Alter their attributes (passwords, capabilities, etc.); one particularly
     useful new feature is the ability to add or subtract capabilities without
     having to re-specify them all.

   * Copy accounting structure.

   * Create an MPEX command file that will rebuild their accounting structure
     when you execute it (perhaps after a later RELOAD or on another machine).

   * Purge them (of course, after first being prompted for verification).

   * If you're an MPEX user, perform an arbitrary set of commands on each of
     them (much like MPEX's %REPEAT ...  %FORFILES lets you perform an
     arbitrary set of commands on each file in a fileset).

IMPORTANT WARNING -- READ ME!!!


Important warning -- read me!!! ``contents
Important warning -- read me!!!

VEAUDIT tries to catch many possible security breaches in your system.
However, it does not and can not catch them all! It is still your
responsibility to keep your system security as tight as possible; when VEAUDIT
reports no violations, IT ONLY MEANS THAT IT COULDN'T FIND ANY VIOLATIONS --
not that no violations actually exist.

VESOFT, Inc.  makes no warranty of any kind with regard to this product,
including, but not limited to, the implied warranties of MERCHANTABILITY and
FITNESS FOR A PARTICULAR PURPOSE.

VESOFT, Inc.  shall not be liable for errors or omissions contained within
VEAUDIT or any reports generated by VEAUDIT or for incidental or consequential
damages in connection with its furnishing, performance or use.

Note also that, as we said before (it's worth repeating!), the VEAUDIT Auditing
Report is a VERY SENSITIVE DOCUMENT, and should be kept COMPLETELY
CONFIDENTIAL.  If an unauthorized user sees it, he'll be able to see how to
break into the system! We only allow users with SM capability and users in the
VESOFT account (which should be tightly secured!) to generate the VEAUDIT
report -- however, we have no way of securing the hardcopy listing! Make sure
that no unauthorized people (including your operators) get a chance to see the
report!

VEAUDIT: BOTH FOR USERS AND NON-USERS OF SECURITY/3000


VEAUDIT: Both for users and non-user of SECURITY/3000 ``contents
VEAUDIT: Both for users and non-user of SECURITY/3000

VEAUDIT's job is to find possible loopholes in your security configuration.
For example, VEAUDIT will show you (among other things) which users have no
passwords, which users have no passwords and have SM or PM capability, etc.

But what do we mean by "no passwords"? If you use SECURITY/3000, in addition to
looking up the user's MPE passwords in the system directory, VEAUDIT must also
check to see if a user (who may not have an MPE password) has a SECURITY
password.  If he does, then it would be wrong to report him as "not having a
password", since he is actually perfectly well protected by his SECURITY
password.  (Many SECURITY users largely avoid MPE passwords altogether --
imagine seeing a report that shows hundreds of users as allegedly "not having a
password" whereas they really do have a SECURITY password! The really
passwordless users would get lost amidst all the falsely-reported passwordless
ones.)

We recommend that SECURITY/3000 users (of whom there are more than 4000 as of
this printing, representing about 6000 CPUs) first read the chapter about
VEAUDIT And SECURITY Passwords.  People who don't use SECURITY can skip that
chapter and any others that have to do solely with SECURITY.  VEAUDIT will give
you much valuable information in either case.

(NEW) VEAUDIT ON MPE/iX 5.0 SYSTEMS THAT SUPPORT POSIX


VEAUDIT on MPE/iX systems that support POSIX``contents`news
VEAUDIT on MPE/iX systems that support POSIX

With the release of 5.0 of the MPE/iX operating system, MPE supports what is
known as POSIX and the Hierarchical File System (HFS).  Overall, this doesn't
affect the operation of VEAUDIT for reporting purposes -- there is no change to
the way users log onto a system, and at this time, it is not possible to put
dangerous programs into POSIX directories.  It is possible, however, to put
jobstreams (which might have embedded passwords) into a POSIX directory, so
there are a couple of things to consider when submitting a VEAUDIT report on an
MPE/iX 5.0 system:

   *  Long file names: Since it is possible for POSIX filenames to be longer
      than MPE filenames, any report that deals with FILES may appear slightly
      different than portrayed in this manual.  This is to accommodate the
      longer filenames and in no way affects the operation of the program.
      These reports are identified in the table of contents with the notation
      "(HFS)".

   *  Using "@" for files in the ROOT (/) DIRECTORY: On POSIX systems, there is
      a special directory known as the ROOT DIRECTORY or "/".  This directory
      contains FILES, DIRECTORIES, and MPE ACCOUNTS.  DIRECTORIES may contain
      FILES or more DIRECTORIES (which, in turn, may contain more FILES or
      DIRECTORIES for several levels).  MPE ACCOUNTS may contain either
      DIRECTORIES or MPE GROUPS, but may not contain FILES.  MPE GROUPS may
      contain either FILES or DIRECTORIES.

      What this means is that FILES may reside either in MPE GROUPS (which can
      only reside in MPE ACCOUNTS) or in DIRECTORIES.  VEAUDIT normally reports
      on MPE FILES or files that reside in MPE GROUPS ONLY, and does not report
      on FILES in DIRECTORIES.  In order to include files in the ROOT DIRECTORY
      or any other DIRECTORY, you must use the "@" to denote "all accounts".


Running VEAUDIT: the Auditing Report ``contents
Running VEAUDIT: the Auditing Report

To generate the VEAUDIT Auditing Report, say:

:RUN VEAUDIT.PUB.VESOFT

(Of course, only users with SM capability and the user MANAGER.VESOFT can run
this program!) VEAUDIT will prompt you for:


Quick reports
Full reports
Selecting reports

  * The type of report you want to output.  Entering "1" gets you a full
     report, "2" gets you a quicker report (which runs faster but does not
     generate some report sections), "3" lets you select specifically which
     sections you want to generate via "yes/no" prompting, and "4" lets you
     specify a list of the sections you want to generate, separated by commas
     (most useful in batch jobs).


Account selection

  * The accounts for which the report is to be generated.  The default is "@"
     for all accounts, but you may want to generate individual reports to give
     to your account managers: simply list the accounts you want to report on,
     separated by commas.  (If you're using a trial version of VEAUDIT, the
     output will always be for all accounts.)


Batch execution

  * Whether you want to run Online ("O") or Batch ("B").  You'd usually want
     to run it in batch, since the report can take quite some time to generate.


Batch execution: scheduling

  * Which :STREAM scheduling parameters you want (if you answered "B" to the
     Online/Batch) prompt; for instance, AT=21:00 will schedule the report for
     9 PM.


Printing the report
REPORT.AUDITDAT.VESOFT, VEAUDIT report file
VEAUDIT output (either online or batch) will be sent to a disc file called
REPORT.AUDITDAT.VESOFT; after the run is done, you can print this file to the
line printer using

:FILE LP;DEV=LP;CCTL
:PRINT REPORT.AUDITDAT.VESOFT;OUT=*LP

or browse it online using MPEX's %PRINT command.  (In fact, VEAUDIT opens the
the report with the ;SHR option, so you can actually look at it while VEAUDIT
is still running!)

Note that WE INTENTIONALLY DO NOT SEND THE OUTPUT TO THE LINE PRINTER! VEAUDIT
output is very sensitive, since -- if there are security loopholes on your
computer and the report is seen by an unauthorized person -- it can give that
person a full road map for breaking into the system.  If you run VEAUDIT
overnight, you definitely do not want its output to go to the line printer,
where it will be visible to any operator or casual passer-by.  Instead, we send
the output to REPORT.AUDITDAT.VESOFT (which should only be readable by users
with SM capability or by MANAGER.VESOFT); then, you can print it out yourself
when you're sure that it will be safe.

If you do feel comfortable sending the printout directly to the line printer,
just say

:FILE REPORT.AUDITDAT.VESOFT;DEV=LP

before running VEAUDIT.PUB.VESOFT (even if you select Batch operation --
VEAUDIT will transfer the :FILE equation from the session to the job).  But be
careful!

INDICATING A SYSTEM NAME FOR REPORT HEADINGS


Indicating a system name for report headings ``contents
Indicating a system name for report headings

If you have more than one computer, you'll probably want to have the VEAUDIT
printouts show which computer they pertain to.  VEAUDIT lets you indicate a
"system name" to be put into your report headers.


HPSYSNAME, MPE/iX variable used by SECURITY ``system`name
HPSYSNAME, MPE/iX variable used by SECURITY
SYSNAME.PUB.VESOFT, special :FILE equation
you're running on an MPE/iX machine, you should just say

:SETVAR HPSYSNAME "systemname"

(e.g.  :SETVAR HPSYSNAME "SYSALPHA") before running VEAUDIT; if you're running
on an MPE/V machine (which doesn't have a :SETVAR command), you can either use
the %SETVAR command of MPEX (since MPEX emulates MPE/iX's new commands) or say

:FILE SYSNAME.PUB.VESOFT=SYSALPHA   << or whatever the name is >>

There doesn't actually have to be a file called SYSALPHA for this to work; the
:FILE equation is a just a way to tell VEAUDIT what the system name is.

If you're going to be running VEAUDIT in batch, just do the :SETVAR or the
:FILE equation online before running VEAUDIT.PUB.VESOFT and specifying the "B"
(batch) option.  VEAUDIT will automatically transfer the :SETVAR or the :FILE
to the background job stream it generates.

(NEW) INSERTING COMPANY SPECIFIC INFORMATION IN THE REPORT


Inserting company specific information in the report``contents`news
Inserting company specific information in the report

You may find it convenient to distribute portions of the report to account
managers who are responsible for security within their account.  While the
notes we supply on how to fix the problems reported should be sufficient for
most companies, you may have additional restraints or safeguards that must be
followed as well.

In order to help you enforce these rules, you may customize the report by
inserting the contents of a text file at the top of each page in each section.
This file may contain information regarding additional security requirements,
useful command files or UDCs that have been implemented, a "confidential"
banner, routing instructions or any other information regarding the contents of
each section of the report.

Using any standard editor, create a text file with your information in it and
/KEEP it as "AUD###.DATA.VESOFT" (Replace the "###" characters with the section
number of VEAUDIT report that corresponds to this file).  When you create
VEAUDIT report, the contents of these files will be included as-is at the top
of each page for each section with a corresponding AUD### file.


Running VEAUDIT: accounting structure maintenance ``contents
Running VEAUDIT: accounting structure maintenance

If you are an MPEX user as well as a VEAUDIT user, the most convenient way for
you to execute these commands is by saying, from MPEX,

%VEAUDIT cmdname parameters

e.g.

%VEAUDIT ALTUSER @.AP-JOE.AP(PASSWORD=""); PASS=LOCKITUP

This syntax is especially convenient if you use it from a HOOKed utility (see
the "MPEX HOOK" chapter of the MPEX User Manual) -- this will let you do
VEAUDIT maintenance tasks even when you're in EDITOR, in QUERY, etc.  You can
also put %VEAUDIT commands into MPEX command files.


VEAUDITCMD, VEAUDIT.PUB.VESOFT entry point
you are not an MPEX user, you can either do a

:RUN VEAUDIT.PUB.VESOFT,VEAUDITCMD;INFO="command"

e.g.

:RUN VEAUDIT.PUB.VESOFT,VEAUDITCMD;INFO="LISTUSER @.@-@.SYS"

or do a

:RUN VEAUDIT.PUB.VESOFT,VEAUDITCMD

which will then prompt you with "%VEAUDIT " for VEAUDIT commands, until you
type "EXIT" to exit.  Note that when you use the VEAUDITCMD entry point, you
should not prefix your commands with "%VEAUDIT ".


VEAUDIT commands, see also SECURITY MENUS in the SECURITY manual
you are a SECURITY user, you can execute VEAUDIT commands within SECURITY
menus (see "Logon Menus Revisited: A Detailed Explanation" in the SECURITY User
Manual).


Getting on-line help ``contents
Getting on-line help
HELP, VEAUDIT.PUB.VESOFT entry point

VESOFT's on-line HELP facility is conceptually oriented; there are very many --
literally thousands -- of keywords you can get help on.  It lets you read this
entire manual (and its index!) online -- just

:RUN VEAUDIT.PUB.VESOFT,HELP

and VEAUDIT will prompt you with

What topic would you like help on (single word only)?

At this point, just type a word (or the first several characters of a word)
that you want help on.

You can also get help when using the VEAUDITCMD entry point:

:RUN VEAUDIT.PUB.VESOFT,VEAUDITCMD
%VEAUDIT HELP [keyword]

where "[keyword]" is the topic you would like to get help on.

If you're an MPEX user, you can get help on VEAUDIT from within MPEX by saying

%VEAUDIT HELP [keyword]

where "[keyword]" is the topic you would like to get help on.

Say you enter the keyword "SM"; VEAUDIT will respond with something like:

  1.  101.  Passwordless users with SM or PM capability
  2.  103.  Globally-readable jobs with SM, PM, OP passwords
  3.  104.  Globally-writable jobs signing on as SM, PM, OP users
  4.  "Trojan horses": Globally-writable job streams with SM, PM, OP
  5.  301.  Users with SM or PM capability
Which of the above would you like help on (or CR to exit)?

You might decide that what you want help on is item #1 ("101.  Passwordless
users with SM or PM capability"), so you enter "1".  VEAUDIT will now display
the manual page that discusses report #101, and will prompt you:

   (F)orward,(B)ack,(>)forward 1/2 page,(<)back 1/2 page,(M)enu,(E)xit?

This lets you page forward and backward through the manual to read the entire
section (which could be several pages).

Note that when HELP shows you the manual page describing the thing you asked
for, the actual description will start about a third of the way down the
screen; thus, it displays about eight lines of manual text that comes before
the description as well as the description itself.  This is done because the
text that immediately precedes the description is often (though not always)
related information that might be useful to you as well.  As long as you
remember that the thing you asked for actually starts at about line eight or
nine of the screen, you shouldn't get confused.

When you're done reading the manual, you can type "E" to exit the HELP facility
or "M" to get back to the SM keywords menu we showed above (in case you realize
you chose the wrong option).

The online HELP index is even more useful than the index in the back of the
printed manual, since the %VEAUDIT HELP command finds all the index entries
that contain the given keyword (not just those that start with that keyword).

A few special keywords you can get help on are:

   INTRODUCTION         gives you a general introduction to VEAUDIT
   CONTENTS             on-line access to the Table Of Contents
   NEWS                 new features of VEAUDIT


The VEAUDIT auditing report ``contents
The VEAUDIT auditing report

THE VEAUDIT REPORT IN A NUTSHELL


The VEAUDIT report in a nutshell ``contents
The VEAUDIT report in a nutshell

The VEAUDIT report actually consists of a number of different sections, each
one describing different aspects of system security.  The sections are printed
in descending order of severity (the most serious security breaches are printed
first).

   * Sections #1xx describe very serious security problems.  In them, we show
     what we think are almost certainly major security loopholes -- for
     instance, SM users without password.

   * Sections #2xx describe less serious but still important security concerns;
     these are not necessarily problems but are still things you should watch
     out for.  For example, this would include users without passwords or users
     with easily guessable passwords.

   * Sections #3xx and #4xx document various security-related issues (such as
     users who have PM capability).  These are the sorts of things that could
     very well be proper, but are still worth looking into.

   * Sections #8xx are for information only.  In these sections we don't so
     much isolate security problems as show you the current state of the system
     so that you can easily look over it to make sure that everything's OK.

This makes it easier for you to get maximum benefits from a minimal investment
of time.

Each report section is documented in greater detail later on in this manual.


#101. Passwordless users with SM or PM capability ``contents`report
#101. Passwordless users with SM or PM capability

One of the worst security breaches you can have on your system is a user that
has System Manager (SM) or the equally-powerful Privileged Mode (PM) capability
and does not have a password.  Anybody can sign on as this user and then do
ANYTHING THEY PLEASE to your system!

Section #101 of our report shows you all such users.  This is, however, more
complicated than it at first glance appears.  Users can have access to SM and
PM capability in one of three ways:

   * They can actually possess SM or PM capability.

   * They can lack SM or PM capability, but be Account Managers (AM) of
     accounts that have SM or PM -- in this case, they can give themselves SM
     or PM any time they choose.

   * They can lack SM or PM capability, but have Write or Save access to a
     group in their account that has PM capability.  Any user with Write or
     Save access to a PM group can get PM capability rather easily.

A sample report might thus show:

User TEST    .AP       has no password and SM and PM
User JACK    .DEV      has no password and is AM of account with SM
User CLERK   .PAYROLL  has no password and has write or save access
                         to the PM group DATA

All three of these are very serious security breaches, and should be remedied
as quickly as possible by:

   * Imposing user, account, and/or SECURITY passwords on the users involved.

   * Investigating whether you can actually take away SM, PM or AM capability
     from the given user -- sometimes a user may have one of those capabilities
     without really needing it.

   * Protecting the PM groups involved.  This involves making sure that Write
     and Save access are allowed to as few users as possible, perhaps to nobody
     (except for AM and SM users, who can always access them).

     The best way of doing this is to say:

:ALTGROUP group;ACCESS=(R,L,X:AC)

     (actually, the ;ACCESS= parameter should indicate whatever access is
     appropriate as long as it does not include the "W" and "S" specifiers).
     This ;ACCESS= parameter will guarantee that only the system manager and
     the account manager can write to this group or save in it.

SECURITY/3000 CONSIDERATIONS

If you use SECURITY, there are actually several ways in which users can be
passwordless (see the VEAUDIT And SECURITY Passwords chapter for more details):

   * They can lack MPE passwords and not be protected by SECURITY (i.e.  not
     included in the $VEPROFILE keywords in the SECURCON.DATA.VESOFT
     configuration file).

   * They can lack MPE passwords but be protected by SECURITY only on-line.
     This can happen if the SECURCON.DATA.VESOFT file does not have any
     $BATCH-VEPROFILE keywords or the $BATCH-VEPROFILEs it has does not include
     the user in question.

   * They can lack MPE passwords and be protected by SECURITY but have their
     SECURITY user ID (IDentification) configured without SECURITY passwords
     (as SECURITY allows a manager to do).

SECURITY identifies each of these situations separately.  A sample report may
show:

User TEST    .AP       has no password and SM and PM
User JACK    .DEV      has no password in batch and is AM of
                         account with SM
User CLERK   .PAYROLL  has no password and write access to
                         PM group DATA
  Passwordless access as SECURITY user PETE    ,CLERK   .PAYROLL
                                            TESTING ,CLERK   .@

This shows that:

   * TEST.AP has no MPE password, is not protected by SECURITY passwords, and
     has SM and PM capabilities.

   * JACK.DEV has no MPE password, is protected by SECURITY passwords (but not
     in batch), and is AM of an account (DEV) that has SM capability (even
     though he himself does not currently have SM).

   * CLERK.PAYROLL has no MPE password, has write access to the privileged
     group DATA.PAYROLL, and can be accessed without SECURITY passwords using
     the SECURITY user IDs of PETE,CLERK.PAYROLL and TESTING,CLERK.@ (which
     were configured without passwords).

Our recommendations in these cases (in addition to the general ones we
discussed above) are:

   * Protect with $VEPROFILE and $BATCH-VEPROFILE those users that aren't
     already protected with them.

   * Set up SECURITY passwords for all the users that are configured in
     SECURITY without passwords.


#102. Globally-writable program files in PM groups``contents`report
#102. Globally-writable program files in PM groups


Trojan horses: Globally-writable programs in PM groups
WRITABLE (or :RELEASEd) PROGRAM file in a GROUP WITH PM CAPABILITY can be
used as "Trojan horse" to break into your system and acquire PM.  They must be
properly secured!

VEAUDIT section #102 shows such files.  For instance, it may tell you:

File REPPRT  .PROG    .AP       is a program in a globally-writable
                                  PM group!
File MYPROG  .PUB     .UTIL     is a :RELEASEd program in a PM group!
File XCOPY   .PUB     .UTIL     may be written to by JOE.PROD

Note that if a file's ACD (Access Control Definition) permits a user to write
to it, we will list the file (and the user) in this report.  Although the file
is not writable by everybody, it's still a possible problem even if one user
has write access to it -- in general, there's no need to allow anybody write
access to program files.

HOW TO FIX THIS PROBLEM

As we saw in the above example, there are three reasons why a program might
show up on this report:

   * It's :RELEASEd -- a :RELEASEd file is always writable by anybody.  In this
     case, the best solution is to promptly :SECURE the file.  This might also
     make it un-:RUNable by anybody.  If you don't like this, move the program
     to a group that has EXECUTE access granted to everybody, e.g.

:NEWGROUP PRIV.UTIL;ACCESS=(X:ANY);CAP=IA,BA,PM

     Then the program can be run by anybody without being writable by them.
     Never :RELEASE a program file in a privileged group!

   * It's in a group that can be written to by anybody.  You should either
     :ALTGROUP this group to restrict write access to it, e.g.

:ALTGROUP PUB.UTIL;ACCESS=(R,X,L:ANY;W,A,S:GU);CAP=IA,BA,PM

     or (if there are other files in this group that need to be writable by
     anybody) move the programs into a separate group.

     In fact, if you move all the programs out into a different group (one with
     Write access restricted), then you can take PM capability away from the
     Write:ANY group, since groups without program files don't need PM (or any
     other capability).

   * Its ACD specifically grants Write access to a particular user (or to all
     users of a particular account or even to @.@).  There's no reason why
     anybody should have to write to a program file -- you should probably
     :ALTSEC it to remove Write access from any users who have it.

POSIX note: Although it is possible to put program files in POSIX directories,
            the initial release of MPE/iX 5.0 does NOT allow PM programs in
            POSIX directories.  This is due, in part, to the fact that
            "directories" cannot have PM capability.  This may change with a
            future release of the operating system, so don't be surprised if
            this report shows programs in POSIX directories.

#103. Globally-readable jobs with SM/PM/OP passwords


Embedded passwords
's :STREAM command normally requires you to embed your passwords in your job
streams.  This means that anybody who can read the job stream will see the
passwords right there in the job card.

Because of this, you should take particular care to secure any of your job
streams that contain embedded passwords, especially passwords of SM/PM/OP
user/accounts/groups.  Otherwise, somebody who's "browsing" through your system
can easily stumble onto one of these jobs and see the passwords inside it.

Section #103 shows you all such dangerous job streams -- all job streams that:

   * can be read by anybody in the system, and

   * contain embedded passwords of users, accounts or groups that have SM, PM
     or OP capability.

For example, the output could look like this:

-------FILENAME-------  CONTAINS PASSWORDS OF      OBJECT INVOLVED
                        USER/ACCOUNT/GROUP         HAS CAPABILITIES:
BUILDJOB.JOB.CONTLIB    Account          CONTLIB   PM   (*2*)
BUILDJOB.JOB.CONTLIB    Group   PROG    .CONTLIB   PM   (*2*)
COMP102 .JACK.DEV       User    JACK    .DEV       OP   (*1*)
BACKUP  .JOB.SYS        User    MANAGER .SYS       SM,PM,OP   (*1*)

We show you the name of the stream file, the objects (users, accounts, or
groups) whose passwords are embedded inside it, and the capabilities that these
objects have.  We also indicate whether the file is :RELEASEd (marked (*1*)) or
whether it resides in a group that is readable by anybody (marked (*2*)).  (The
(*1*) and the (*2*) are also explained at the bottom of the report printout in
the "RECOMMENDATIONS" section.)

Note that -- in addition to files that are globally-readable -- we also show
you job streams that have ACDs (Access Control Definitions) which specifically
allow Read access to particular users.  Although these files are not actually
globally-readable, they are still potential problems because those users can
learn the passwords by looking at the job streams.  Since Read access to a file
is not required to :STREAM it (eXecute access is sufficient), you should
probably :ALTSEC these files to prohibit Read access to everybody.

POSIX note: Since it is possible to put job streams in a POSIX directory, this
            report will show POSIX files in any groups and subdirectories of an
            account.  If the filename is too long to fit in the space provided,
            the remaining information about the violation (user ID and
            capabilities) will be displayed on a new line.

Once you find all these stream files, you should immediately secure them.
There are several ways of doing this:

   * If possible, remove the embedded passwords from the job stream and start
     using a program (such as SECURITY's STREAMX) that lets you stream jobs
     that don't have embedded passwords (by prompting you for the passwords at
     stream time - or by special permission).

     Embedded passwords are bad -- not just because they make it easier for
     people to see passwords that they shouldn't see.  They also make it much
     more difficult for you to change your passwords (which, of course, you
     should do periodically), since this would involve changing dozens of job
     streams, too.  Sites that use embedded passwords typically don't change
     their passwords for years just because the change would be so
     inconvenient.

   * Alternatively, you can secure the job file to prevent people from reading
     it.

     There are two reasons why a job stream (or any file) may be readable by
     everybody in the system.  One is if the file is :RELEASEd -- if it is,
     :SECURE it! When you :RELEASE a file, you're letting anybody do ANYTHING
     to it.

     The other possible reason is that the job stream is in a group, account or
     directory that allow read access to everybody.  If this is the case, you
     should tighten at least the group security with the :ALTGROUP command,
     e.g.

:ALTGROUP JOB.CONTLIB;ACCESS=(R,A,W,L,X,S:GU)

     This command would restrict JOB.CONTLIB so that files in it (at least
     non-:RELEASEd files) can only be accessed by users that are signed on to
     this group (or by the account or system manager).  You might also say:

:ALTGROUP JOB.CONTLIB;ACCESS=(R,A,W,L,X,S:AC)

     to let anybody in the CONTLIB account access files in JOB.CONTLIB, but be
     careful -- even that may be too lax for protecting your SM/PM/OP
     passwords!

     If a file is shown on the report as being accessible by specific users
     (because of its ACD), you can use the :ALTSEC command to take away Read
     access from those users.  You can also use the :ALTSEC ;NEWACD= command to
     impose a new ACD on an otherwise globally-readable (:RELEASEd or in a
     R:ANY group) file:

:ALTSEC BUILDJOB.JOB.CONTLIB;NEWACD=(X:@.@)

     will permit everybody to stream this file (X access) but forbid everybody
     but the file's creator, account manager of the file's account, and system
     manager from reading the file (or doing anything else to it).

Note that when we say that a job has an embedded password, we mean a correct
embedded password.  If the embedded password is incorrect -- usually if the
password has been changed since the job was last run -- we will not report the
job as having an embedded password.

ALSO NOTE: The report requires reading all potential job streams on your
system.  This will take some time; however, it will not alter the last access
dates of the files being read.  (We take special measures to make sure of
this!)


#104. Globally-writable jobs signing on as SM, PM, OP users``report
#104. Globally-writable jobs signing on as SM, PM, OP users


Trojan horses: Globally-writable job streams with SM, PM, OP
one of your nightly job streams that signs on as MANAGER.SYS (e.g.
your backup, your periodic spool file cleanup, etc.).  You stream it every
night -- perhaps it even schedules itself automatically.  You certainly don't
look at it before you stream it (after all, it's the same every time) -- you
probably don't pay very close attention to its $STDLIST, either.

Now, let's say that this job stream is inadvertently :RELEASEd (or is kept in a
group that is writable by everybody).  What's to stop somebody from adding an
:ALTUSER command to this job stream that grants a user SM capability? And maybe
even a ":SET STDLIST=DELETE" so nobody will see what happened!

This is a classic "Trojan horse" security violation, and the only way to stop
it is to make sure that your job streams, especially those that sign on as SM,
OP or PM users, are properly protected against unauthorized writers.

Section #104 shows you all job streams that sign on as SM/PM/OP users and are
globally-writable.  It also shows you any SM/PM/OP job streams whose ACDs
(Access Control Definitions) specifically permit write access to particular
users; even though this is not as bad as permitting write access to everybody,
this is still a potential problem, especially because there's usually no need
for anybody to have Write access to a job stream.

For instance:

-----FILENAME-----  LOGS ON AS          OBJECT INVOLVED    WRITABLE
                    USER/ACCOUNT/GROUP  HAS CAPABILITIES:  BY

PS010J.OPER.PROD    OPER   .PROD  ,PUB  OP (*2*)           (*4*) @.DEV,
                                                           JOE.PROD
BACKUP.JOB .SYS     MANAGER.SYS   ,PUB  SM,OP,PM (*1*)

Files marked "(*1*)" are :RELEASEd files -- they should be :SECUREd.  Files
marked "(*2*)" reside in groups that have write access allowed to anybody; you
should restrict them by saying something like:

:ALTGROUP OPER.PROD;ACCESS=(R,L,X:ANY;W,A,S:GU)

or any such command that restricts Write access to as few users as possible.
Files marked "(*4*)" have ACDs that specifically allow write access to certain
users (which we list) -- you should :ALTSEC these files to prohibit Write
access.


#105. Users who may disable system UDCs ``turn`off`contents`report
#105. Users who may disable system UDCs

Many security systems rely on UDCs.  Unfortunately, if you don't properly
protect your COMMAND.PUB.SYS file, anybody can temporarily disable system UDCs,
thus defeating your security.

In general, anyone who has Read or Append access to COMMAND.PUB.SYS (which all
users have, by default) can defeat system UDCs this way.  (For security
reasons, we won't explain exactly how, but we assure you that it's quite
possible.)

VEAUDIT section #105 tells you if your COMMAND.PUB.SYS is accessible by
unauthorized users (and thus your UDC security is in jeopardy).  It can tell
you one of several things:

   1.  ***ANY USER*** MAY DISABLE SYSTEM UDCs!

      This means that COMMAND.PUB.SYS is accessible in Read, Write, or Append
      mode by any user in the system, and thus system UDCs can be turned off by
      anybody who has access to the Command Interpreter.

   2.  SOME USERS MAY DISABLE SYSTEM UDCs!

      This means that COMMAND.PUB.SYS is accessible in Read, Write, or Append
      mode by some or all users in the SYS account.  If you trust all your SYS
      account users, this should be no problem; however, you might well decide
      that, say, OPERATOR.SYS shouldn't have this sort of power.

      Specific cases of this include:

         - ANY USER IN THE SYS ACCOUNT MAY TEMPORARILY DISABLE UDCs.  This
           means that Read/Write/Append access to COMMAND.PUB.SYS is granted to
           all SYS account users.

         - THE USER(S) xxx.SYS MAY TEMPORARILY DISABLE UDCs (SINCE HE HAS AL
           CAPABILITY).  This means that Read/Write/Append is allowed only to
           users with AL capability, which includes the user (or users) listed.

         - ANY USER IN THE SYS ACCOUNT WHO SIGNS ON TO THE (PASSWORDLESS) PUB
           GROUP MAY TEMPORARILY DISABLE UDCs.  This means that
           Read/Write/Append is allowed only to users who log on to PUB.SYS,
           but any SYS user could do so because the PUB group has no password.

         - THE USER(S) xxx.SYS MAY TEMPORARILY DISABLE UDCs BY SIGNING ON TO
           THE (PASSWORDLESS) PUB GROUP (SINCE HE HAS GL CAPABILITY).  This
           means that Read/Write/Append is allowed only to users with GL
           capability (which includes the user or users listed) who sign on to
           the passwordless PUB group.

         - SPECIFIC USERS ARE GRANTED READ/WRITE/APPEND ACCESS BY AN ACD
           (Access Control Definition) on COMMAND.PUB.SYS.

   3.  YOUR COMMAND.PUB.SYS FILE IS PROPERLY SECURED.

      This means that you have properly set up the security on COMMAND.PUB.SYS
      (allowing at most eXecute and Lock access to it) -- this should prevent
      people from disabling system UDCs by improperly accessing
      COMMAND.PUB.SYS.

HOW TO FIX THIS PROBLEM

The appropriate way to secure COMMAND.PUB.SYS is to say

:HELLO MANAGER.SYS
:ALTSEC COMMAND.PUB.SYS;(X,L:ANY)
:SECURE COMMAND.PUB.SYS

This will prohibit anybody (except SM users) from accessing COMMAND.PUB.SYS
improperly and thus temporarily disabling system UDCs.

The only possible problem with this is if some program (typically one that
emulates MPE's UDCs) has to open COMMAND.PUB.SYS with Read access.  VESOFT's
MPEX, which does UDC emulation, does not require Read access, but some programs
might.


CMDPROT, BACKG task that protects COMMAND.PUB.SYS
you find that you have to use such a program, you may be forced not to do
the above :ALTSEC; however, in that case you'll have to either live with the
security hole we've been talking about or start the CMDPROT task under the
BACKG job.  To do this, enter the following commands:

%VEAUDIT BACKG STARTJOB        (* If it's not already running *)
%VEAUDIT BACKG START,CMDPROT

AND MAKE SURE THAT THE 'CMDPROT' TASK REMAINS RUNNING ALL THE TIME.

(Please see the documentation for %BACKG in the "MPEX Commands" section of the
MPEX User Manual for details.) CMDPROT protects COMMAND.PUB.SYS and prevents
improper access to it without your having to :ALTSEC it.  Programs that require
read access to COMMAND.PUB.SYS should then keep running.  (CMDPROT will not
impose any performance overhead on your system.)


#106. Passwordless users with OP capability ``contents`report
#106. Passwordless users with OP capability

Though OP capability is not as dangerous as SM or PM, it does give a user a lot
of power.  In particular, an OP user can :STORE and :RESTORE any file in the
system; thus, indirectly, he can read and write any file in the system.  Also,
he can dump the system directory to tape, read the resulting tape, and see all
the passwords in the directory!

Thus, a user who has OP capability but no password is a potentially nasty
security threat.  Section #106 shows you all such users, as well as users who
don't actually have OP but are Account Managers (AM) of accounts that have OP
capability.

The format of the output is very similar to that of Section #101, which shows
users who have SM and/or PM but no passwords.  Just as Section #101, Section
#106 takes into account SECURITY passwords, the SECURITY $BATCH-VEPROFILE
keyword, and SECURITY users who were configured without passwords.  (For more
information on this, see the Section #101 documentation.)

A sample output might look like this:

User MILLARD .DEV      has no password and is AM of account with OP
User OPER    .PROD     has no password and OP

This shows that:

   * User MILLARD.DEV has no passwords and is Account Manager of an account
     that has OP capability.  Though Millard doesn't have OP himself, he can
     easily get it.

   * User OPER.PROD has no passwords and has OP.

We recommend that you put user, account, and/or SECURITY passwords on all the
users we list; or, for users who are AMs of an account with OP, take away their
AM capability.  You should also examine the list closely to see whether all of
these users really need OP -- most probably do, but there may be some who
really have no need for it.


#107. SECURITY/3000 logon UDC set-up problems ``contents`report
#107. SECURITY/3000 logon UDC set-up problems

SECURITY's logon security only works for those users for whom the UDC file
LOGONUDC.PUB.VESOFT is properly set up.  We encourage all our customers to set
the SECURITY logon UDC for the entire system; however, some people may not do
this, and others might do this, but somewhat erroneously (for instance, they
might not have the necessary OPTION NOBREAK set for this UDC).

The #107 report shows you for whom the SECURITY logon UDC is correctly set and
for whom it is incorrectly set.  If the output says:

***************************************************************
#107.  THE SECURITY LOGON UDC APPEARS TO BE PROPERLY SET UP
***************************************************************

this means that the SECURITY LOGON UDC is set system-wide; otherwise, the
report might say:

The SECURITY OPTION LOGON UDC is NOT set system-wide.   (*1*)
It is properly set for account PROD.
It is properly set for account SYS.
It is properly set for user MGR.AP.
It is set without OPTION NOBREAK for account PAYROLL.   (*2*)
It is inhibited by another LOGON UDC on the same level
   for account GL.   (*3*)

This indicates that:

   - The SECURITY OPTION LOGON UDC is set (and thus SECURITY logon security is
     enforced) for the accounts PROD and SYS, and for the user MGR.AP.

   - The SECURITY OPTION LOGON UDC is set but without OPTION NOBREAK for the
     account PAYROLL.  This means that the user will go through SECURITY, but
     will always be able to hit [break], :ABORT, and then have access to MPE.

   - The SECURITY OPTION LOGON UDC is set for the GL account, but a different
     OPTION LOGON UDC set on the same level (in this case, on the account
     level) prevents the SECURITY UDC from being executed.  MPE will only
     execute the first logon UDC on each level (system, account, and user) when
     a user logs on; if the SECURITY invocation is not part of the first logon
     UDC on a level, it will not get executed.

RECOMMENDATIONS

First of all, we recommend that you set the LOGONUDC.PUB.VESOFT UDC file for
the whole system, i.e.  just do a

:SETCATALOG LOGONUDC.PUB.VESOFT,your other system UDCs;SYSTEM

You can still configure (via the SECURCON.DATA.VESOFT file) to whom all the
SECURITY options apply, so setting the UDC system-wide doesn't mean that, say,
SECURITY user profiles applies to everybody.  However, having the UDC set
system-wide makes it a lot easier for you to configure new SECURITY options for
users, since all you'd have to do is modify the SECURCON file and the UDC will
automatically put the modifications into effect the next time a user signs on.

Secondly, it is imperative that your OPTION LOGON UDC that runs SECURITY has
OPTION NOBREAK,LOGON (not just OPTION LOGON).  We recommend that you use our
LOGONUDC.PUB.VESOFT UDC FILE -- it contains just the right options and commands
that are needed.

If you have to put the text of the UDC into your own system UDC file, be sure
that you put it into an OPTION NOBREAK,LOGON UDC.  Also, you must check our
LOGONUDC.PUB.VESOFT file each time you install a new version of our software.
Sometimes we make changes to it!

Thirdly, the OPTION LOGON UDC that runs SECURITY must be the first OPTION LOGON
UDC on its particular level; if you have more than one thing that you need done
at logon time, you'll have to merge the UDCs.

Note that this report doesn't check for all possible problems; it is possible
for you to set up a UDC that looks to VEAUDIT like a valid SECURITY logon UDC
but in reality has some flaw (e.g.  a logic error or the possibility of a UDC
abort before SECURITY is run) that will keep SECURITY from being properly run.

As we've said about all the other reports, we can only catch some of the
possible errors; the rest will have to be found by you.  However, this report
does show you several of the most common problems that may occur when you set
up the SECURITY OPTION LOGON UDCs.


#201. Passwordless users ``contents`report
#201. Passwordless users

If you have a user who has neither an MPE password nor a SECURITY password,
then anybody can sign on as that user.  We strongly recommend that all users
have at least some sort of password protection -- otherwise, your system would
be wide open.

Section #201 shows you all the users that have neither MPE passwords nor are
protected by SECURITY passwords.  (See the VEAUDIT And SECURITY Passwords
chapter for some technical details on when a user is considered to have a
SECURITY password.) A sample report might simply say:

User TEST    .AP       has no password
User JACK    .DEV      has no password
User CLERK   .PAYROLL  has no password

All of those users should be protected by MPE or SECURITY passwords.  It's much
harder to secure a system from somebody who is already logged on (even if he's
logged on as a very low-capability user) than from somebody who can't log on in
the first place.

SECURITY/3000 CONSIDERATIONS

As we mentioned before (and as we discuss in more detail in the VEAUDIT And
SECURITY Passwords chapter, and in the section #101 above), there are actually
several ways in which SECURITY users can be passwordless:

User TEST    .AP       has no password
User JACK    .DEV      has no password in batch
User CLERK   .PAYROLL  has no password
  Passwordless access as SECURITY user PETE    ,CLERK   .PAYROLL
                                            TESTING ,CLERK   .@

This indicates that:

   * User TEST.AP has no password (either MPE or SECURITY)

   * User JACK.DEV has no MPE password, and although he is protected by
     SECURITY passwords online, he isn't protected by them in batch

   * User CLERK.PAYROLL has no MPE password and can be accessed without user
     passwords using the SECURITY profiles indicated (PETE,CLERK.PAYROLL and
     TESTING,CLERK.@).

Note that it is possible for a user to be password-protected using group
passwords, without any user, account or SECURITY passwords.  This only works if
all groups in the user's account have passwords and the user has no home group.
If we find such a user, we will not report him as passwordless, since he is
indeed protected by his account's group passwords.


#202. Inappropriate MPE passwords ``contents`report
#202. Inappropriate MPE passwords


Vendor default MPE passwords
Guessable MPE passwords
's amazing how many passwords are, say, equal to the user name, or only a few
characters long or are set to system defaults (e.g.  "HPONLY" for HP's
MGR.TELESUP).  These passwords give you the illusion of security, while in
reality leaving you wide open.

Let's not even talk about the hackers at home with their PCs who have
password-guessing programs that cycle through commonly-used English words --
some of these passwords (e.g.  those set to be equal to the user name) can
easily be guessed by almost anybody!

VEAUDIT lets you find all such inappropriate passwords, and even allows you to
specify which passwords you consider inappropriate (more about this shortly).

Section #202 of the VEAUDIT Report might give you a printout that looks
something like this:

Account          ADMIN     Password is too easy to guess
   User MGR     .ADMIN     Password same as user name
Account          DEV       Password same as account name
  Group DATA    .DEV       Password is too easy to guess

By default, passwords are checked to make sure that they are:

   * For user passwords, not equal to the user name (i.e.  "MGR.ADMIN"'s
     password is not supposed to be "MGR").

   * For group passwords, not equal to the group name (i.e.  "DATA.ADMIN"'s
     password is not supposed to be "DATA").

   * Not equal to the account name (i.e.  "MGR.ADMIN"'s password is not
     supposed to be "ADMIN").

   * Not equal to some commonly-abused values (e.g.  "PASS", "PASSWORD",
     "SECRET", "HPONLY", and certain other third-party vendor default
     passwords).

   * Not equal to "RESTOREP", the password that the :RESTORE...;CREATE command
     assigns to all users, accounts and groups that it creates.

What if you want to flag other values that you believe to be inappropriate? For
instance, you might want to flag some common people's names, car makes, etc.
-- whatever you feel might be too easily guessable and people are likely to
abuse.

To do this, you should modify the file called BADPASS.AUDITDAT This file might
contain something like the following:

PASS    "Too easy to guess"
JANE    "Person's first name"
SAM     "Person's first name"
TOYOTA  "Make of car"

Each line indicates which password is to be rejected, and what message is to be
printed on the report in case the password is found.  There's no fixed format
to the line; it must simply contain the password-to-be-flagged, one or more
spaces, and then the error message (in quotes).  We supply you a
BADPASS.AUDITDAT.VESOFT file that has some of the passwords that we think are
particularly bad, and you can build on top of that.


#203. Inappropriate SECURITY passwords ``contents`report
#203. Inappropriate SECURITY passwords


Guessable SECURITY passwords
Identical SECURITY passwords
as VEAUDIT catches inappropriate MPE passwords, it also flags
inappropriate SECURITY passwords.  It catches SECURITY passwords that are equal
to the account name, equal to the user name, equal to the session name, equal
to certain easily-guessable constant values, etc.  -- just like the
inappropriate MPE passwords report.  For example, this report might look like
the following:

User MARY,CLERK.AP       PASSWORD #1 Too easily guessable
User JOHN,@.AP           PASSWORD #2 Too easily guessable
                         PASSWORD #3 Same as session name
User CHESTER,OPER.PROD   ALL 5 PASSWORDS IDENTICAL!

Note that we check each one of the several SECURITY passwords you may have
configured for each user (though if you've only configured one per user, we'll
handle that, too).

We check the passwords to make sure that:

   * They're not the same as the SECURITY user's account name, user id or
     session name;

   * They're not the "bad passwords" listed in the BADPASS.AUDITDAT file (see
     the Inappropriate MPE Passwords) chapter above.

If you use multiple SECURITY passwords, we also make sure that each user's
passwords are all set to different values (some lazy users set them all to the
same value for convenience).


PASS-EDIT, SECURITY keyword
$PASS-EDIT, SECURITY keyword
SECURITY passwords are encrypted, we can't check their length to make
sure that the passwords are at least 5 characters long.  However, you can
prevent these passwords from arising at all using the $PASS-EDIT feature of
SECURITY (see the SECURITY User Manual for more details).

It is possible (though unlikely) for SECURITY's one-way password encryption
scheme to map two different passwords into the same value; thus, somebody could
enter a perfectly reasonable password that VEAUDIT will think is inappropriate
because the entered password and the inappropriate password map to the same
value.  However, this should occur very infrequently.

#204. globally-readable jobs with embedded passwords

As we talked about earlier (in the discussion of section #103),
globally-readable job streams with embedded passwords are quite dangerous --
anybody in the system can look at them and see the passwords right there in
plain text.

Section #103 showed you the globally-readable job streams with embedded
passwords of SM, PM or OP users/accounts/groups.  These are the most dangerous
cases, but even a normal password that's embedded in a globally-readable job
stream is a bad thing.  After all, what's the use of a password if any user on
the system can find it out?

Section #204 shows you all globally-readable job streams with embedded
passwords, e.g.:

-------FILENAME-------  CONTAINS PASSWORDS OF      OBJECT INVOLVED
                        USER/ACCOUNT/GROUP         HAS CAPABILITIES:
ARCHIVE .JOB.AP         User    MANAGER .AP        (*2*)
APMAINTJ.JOB.AP         User    MANAGER .AP        (*2*)
COMP102 .JACK.DEV       User    JACK    .DEV       OP   (*1*)
REMJOB.JOB.SYS          User    MANAGER.PROD       [sysb]

Again, these jobs are divided into three classes:

   * Those marked (*1*), which are globally-readable because they're :RELEASEd
     -- they should be :SECUREd.

   * Those marked (*2*), which are globally-readable because they're kept in a
     group that has read access allowed to anybody.  This group should be
     altered to restrict read access, perhaps only to people in the given group
     or account, e.g.

:ALTGROUP JOB.AP;ACCESS=(R,A,W,L,X,S:GU)

   * Just like in report #103, we show you job streams (marked with a "(*4*)")
     which have Access Control Definitions (ACDs) that specifically permit read
     access to particular users.  Though these files aren't as dangerous as
     those which are readable by anybody, they're still a potential problem,
     especially since Read access isn't required to stream a job (eXecute
     access is sufficient).

In addition to embedded "!JOB" passwords, report #204 also shows you job
streams with embedded "!REMOTE HELLO" passwords.  Since VEAUDIT has no way to
determine the capabilities of a user on a remote system, it shows the
environment ID (which is by default the nodename) of the remote system instead
(in brackets, i.e.  "[sysb]" in the example above).

Even better than securing the stream files is eliminating embedded passwords
altogether.  This can be done by using a program (such as SECURITY's STREAMX)
that doesn't make you embed passwords, but rather prompts for them at stream
time (or inserts them based on special permission).  As we discussed in the
documentation on section #103, embedded passwords make it very difficult for
you to change passwords periodically (which you really ought to do) and thus
endanger your system security.


#205. Globally-writable job streams ``contents`report
#205. Globally-writable job streams


Trojan horses: Globally-writable job streams
we discussed in section #104, job streams that can be written to by anybody
can be used as "Trojan horses" -- somebody could modify the job so that when
it's streamed, it'll do something very different than what its author (or its
submitter) intended.

For instance, if a job logs on as a user with AM capability, then somebody
might modify the job to do an :ALTUSER that will give him (the modifier)
additional capabilities; or, if a job logs on as a user that's authorized to
modify the database, then some other user can modify the job to make some
unauthorized changes to the database.

What this means is that globally-writable stream files are bad for your system
security, and the section #205 report can find them for you.  The section #104
report shows you specifically those globally-writable stream files that sign on
as SM, PM or OP, and are thus the greatest security threat; section #205 shows
you all such globally-writable files:

-----FILENAME-----  LOGS ON AS          OBJECT INVOLVED
                    USER/ACCOUNT/GROUP  HAS CAPABILITIES:

CHECKS.JOB .AP      ANNE   .AP    ,PUB  (*2*)
DBSTAT.JOB .AP      MANAGER.AP    ,PUB  AM   (*2*)
COMP10.SAM .DEV     SAM    .DEV   ,SAM  (*1*)

Just as in section #104, the files are marked (*1*) if they're :RELEASEd (in
which case you should just :SECURE them) and (*2*) if they're kept in a group
that allows write access to anybody.  Also, as in section #104, a (*4*)
indicates that these files have ACDs (Access Control Definitions) that
specifically permit Write access to a particular user; though this isn't as bad
as permitting Write access to everybody, it's still a possible problem,
especially since it's quite rare that anybody (besides the file's creator,
account manager or system manager) would actually need write access to a file.

In the (*2*) case, we recommend that you restrict group access by saying
something like:

:ALTGROUP JOB.AP;ACCESS=(R,L,X:ANY;W,A,S:GU)

or any such command that restricts Write access to as few users as possible.


#206. Passwords that are too short ``contents`report
#206. Passwords that are too short

Often, users value their convenience more than they value system security.
Instead of having passwords that are difficult to guess (and long enough that
an observer can't easily figure them out from the movement of the user's
fingers), they have passwords that are very obvious (e.g.  their own user name)
or too short.

Sections #202 and #203, discussed above, find passwords that are too easy to
guess; section #206 finds passwords that are too short.  By default, it finds
any MPE password that is shorter than 5 characters long (though that can easily
be changed -- see below).  A sample output might say:

Account          AP         PASSWORD ONLY 3 CHARACTERS LONG!!!
   User TOM     .AP         PASSWORD ONLY 4 CHARACTERS LONG!!!
   User VICTOR  .AP         PASSWORD ONLY 2 CHARACTERS LONG!!!

Group   DATA    .DEV        PASSWORD ONLY 3 CHARACTERS LONG!!!

Given this information, you can easily change these passwords to something more
reasonable.


VEAUDITMINPASSLEN JCW, sets min password length to flag
you want to change the password length threshold -- either increase or
decrease it -- from its default value of 5, simply say

:SETJCW VEAUDITMINPASSLEN=newvalue

before running VEAUDIT.PUB.VESOFT.  (Even if you tell VEAUDIT to do the report
in batch, it's enough for you to do the :SETJCW in your session.)


MPE-PASS-EDIT, SECURITY keyword
$MPE-PASS-EDIT, SECURITY keyword
that SECURITY lets you easily impose your own minimum password length on
MPE passwords that are set by users for themselves; look in the SECURITY User
Manual under the "$MPE-PASS-EDIT" keyword.

Also note that we can't find SECURITY passwords that are too short since
they're stored in one-way encrypted form.


#207. MPE PASSWORDS UNCHANGED IN THE LAST 30 DAYS``contents`report
#207. MPE PASSWORDS UNCHANGED IN THE LAST 30 DAYS

The longer a password remains unchanged, the less protection it gives you.
Passwords must be changed periodically to maintain your system security.

Section #207 shows you all the MPE passwords that have not been changed in the
past 30 days (of course, this period is configurable -- more on this shortly).
It also tells you -- if you're a SECURITY user -- to what extent your passwords
are protected by SECURITY's MPE password obsolescence facility; SECURITY can
automatically invalidate any passwords that are older than a particular number
of days.

A sample report might look like this:

----OBJECT----      UNCHANGED IN    ---SECURITY INFORMATION---
                    HOW MANY DAYS?  OBS-   WARN-    PROMPT USER
                                    DAYS   DAYS     TO CHANGE PASS?

Account PROD            46 to 45      60      7     WHEN OBSOLETE
   User JACK.PROD       87 to 80      Obsolescence UNENFORCED

  Group TECH.SYS        70 to 65      90     10
   User PETE.SYS        75 to 74      60      7     DURING WARNING
                                                *** OBSOLETE! ***

As you see, we show all the accounts, users and groups whose passwords have not
been changed in the last 30 days; we indicate:

   * How many days ago the password was last changed.

   * Whether or not SECURITY enforces password obsolescence on this object,
     and, if so, how long it takes for the password to expire and what the
     warning period before expiration will be.

   * Whether the user is automatically asked for a new password when his old
     one has expired (indicated by "WHEN OBSOLETE") or only during the
     pre-expiration warning period (indicated by "DURING WARNING").  A blank
     field here means that the user is not automatically asked for a new
     password.

   * Whether the password has expired (according to SECURITY) -- if it has, we
     indicate it by saying "*** OBSOLETE! ***".


AUDITC, VEAUDIT data capture BACKG task
do we tell you that the password was last changed "46 to 45 days ago"?
Well, MPE doesn't keep track of when a password was last changed; we have to
keep track of this ourselves using our VEAUDIT Data Capture facility, AUDITC
(which also lets us show you, in sections #803 and #804, the MPE and SECURITY
directory changes that have occurred in the recent past).  AUDITC executes as a
task under the BACKG background job; to start it, simply do

%VEAUDIT BACKG STARTJOB        (* If it's not already running *)
%VEAUDIT BACKG START,AUDITC

(please see %BACKG in the "MPEX Commands section of the MPEX User Manual for
details).  By default, it will then run every night at 2:00 A.M., but you can
configure this to any time you wish (again, see the %BACKG documentation for
details).

The "46 to 45 days ago" means that AUDITC ran 46 days ago and also 45 days ago
and detected that the password changed between those two runs.  The "87 to 80
days ago" means that AUDITC must have not been run for a week, so we can't give
you a more precise time.  If you had seen something that said "more than 95",
this means that AUDITC was run for the first time on your system 95 days ago,
and the password hasn't changed since then.

If you turn on the $MPE-OBSOL keyword in SECURITY (to enable automatic
expiration of your passwords), SECURITY will do its own data collection using
the OBSFILL task under the BACKG job.  We'll try to get this data from our
database if possible, and if we can, we'll also display it for you (in a column
marked "ACCORDING TO OBSFILL") -- however, this column may be more or less
precise than the other one depending on how often OBSFILL and AUDITC have been
run on your system.

We recommend that you use BACKG to run AUDITC every night -- it's quite
efficient and will let you get complete and accurate historical information.

CHANGING THE REPORT THRESHOLD (FROM 30 DAYS)


VEAUDITDIRPASSCHGDAYS, JCW ``password`change`expired`days
VEAUDITDIRPASSCHGDAYS, JCW
default, we show you all the passwords unchanged in the past 30 days; you
can change this number by saying

:SETJCW VEAUDITDIRPASSCHGDAYS=60   << or whatever >>

(Even if you tell VEAUDIT to do the report in batch, it's enough for you to do
the :SETJCW in your session.)

WHAT (*2*) MEANS

If you use SECURITY's MPE password obsolescence feature, you might sometimes
see a line marked with an "(*2*)" -- it can either have the "(*2*)" in the
obsolescence or warning days column or it can say "OBSOLESCENCE MAY BE
UNENFORCED (*2*)".

What does this mean? Why does it say "may be" unenforced?

The way that you turn on SECURITY's MPE password obsolescence is by adding
lines to the SECURCON.DATA.VESOFT indicating the keyword (e.g.  $MPE-OBSOL,
$MPE-OBS-DAYS, $MPE-WARN-DAYS), possibly the number of days (e.g.
$MPE-OBS-DAYS 30), and the usersets to which this keyword applies.  Thus, if
you say

$MPE-OBSOL @.AP @.PROD
$MPE-OBS-DAYS 30 @.AP
$MPE-OBS-DAYS 45 @.PROD

then SECURITY will automatically obsolete all passwords in the AP and PROD
accounts, with an obsolescence period of 30 days for the AP account and 45 days
for the PROD account.

VESOFT usersets are very flexible.  You can, for instance, say

$MPE-OBSOL @.@-MANAGER.SYS-ANNE,@.PROD

which means that MPE passwords should be checked for obsolescence for all
logons (@.@) except for MANAGER.SYS and any session in the PROD account that
signs on with session name ANNE.

This can be useful if, say, you don't want to burden particular users with
having to worry about password changes.  (For instance, if ANNE is the account
manager, you may want her to be able to sign on to any user ID in this account
without the possibility of being locked out.)

However, this means that we can't tell you that obsolescence is really enforced
for the SYS account password because at least one user (MANAGER.SYS) can log on
to the account even if the account password is obsolete.  Thus, we tell you
that "OBSOLESCENCE MAY BE UNENFORCED (*2*)" because, depending on how a user
signs on to the SYS account, the last change date of the account may or may not
be checked.

Similarly, we'll tell you that "OBSOLESCENCE MAY BE UNENFORCED" for all group
and user passwords in the PROD account, since when Anne logs on to them, the
last change dates will also not be checked.  The $MPE-OBSOL keyword is probably
still effective, since any users in the PROD account who sign on with any
session name other than ANNE will still be denied access if their passwords are
obsolete; however, since the protection is not complete, we can't tell you that
password expiration is always enforced.

If you see this "(*2*)" indicator, you should refer back to your
SECURCON.DATA.VESOFT data file to see exactly which options are set for which
usersets -- it may be that everything's really all right, but the userset is
too complicated for VEAUDIT to tell you exactly which $MPE-OBSOL, $MPE-OBS-DAYS
or $MPE-WARN-DAYS setting applies.

#208. SECURITY PASSWORDS UNCHANGED IN THE LAST 30 DAYS
208. Password aging

It is not always as necessary to change SECURITY passwords periodically as it
is to change MPE passwords periodically -- if you use personal profile
passwords, you probably do not change them.  However, many users do indeed want
to change their SECURITY passwords to be changed frequently; this report (just
like the #207 report for MPE passwords) shows the age of all the SECURITY
passwords in the system.

A sample #208 report might read:

SESSION USER ACCOUNT   DAYS SINCE  OBSOL  WARN  PROMPT USER
                      LAST CHANGE   DAYS  DAYS  TO CHANGE PASS?

PETE,   MGR  .AP               55     30     5  DURING WARNING
JACK,   CLERK.PROD             43     60     7  WHEN OBSOLETE
@,      OPER .PROD             75  Obsolescence UNENFORCED (*1*)
@,      JANET.SYS              45     30     7  ***CAN'T LOGON!***

As you see, we show:

   * The number of days since the password was last changed.

   * If SECURITY obsolescence is turned on for this user (using the SECURCON
     $VE-OBS-DAYS keyword),

       - the number of days that a password lasts until it becomes obsolete
         (set using $VE-OBS-DAYS);

       - the number of days before password obsolescence that the users is
         warned that his password will soon become obsolete (set using
         $VE-WARN-DAYS);

       - when a user is automatically prompted to change his password ("WHEN
         OBSOLETE" means when his password is obsolete; "DURING WARNING" means
         during the warning period but not once his password has become
         obsoleted -- set using the $VE-OBS-PASSCHG and $VE-WARN-PASSCHG
         keywords);

       - if the password is obsolete and the user can not change it when he
         tries to log on (i.e.  the $VE-OBS-PASSCHG flag is OFF for him), we
         mark the user with a "***CAN'T LOGON!***" message -- this user is
         prohibited from accessing the computer until his account or system
         manager changes his password.

CHANGING THE REPORT THRESHOLD (FROM 30 DAYS)


VEAUDITSECPASSCHGDAYS, JCW ``password`change`expire`obsolete`days
VEAUDITSECPASSCHGDAYS, JCW
default, we show you all the passwords unchanged in the past 30 days; you
can change this number by saying

:SETJCW VEAUDITSECPASSCHGDAYS=60   << or whatever >>

(Even if you tell VEAUDIT to do the report in batch, it's enough for you to do
the :SETJCW in your session.)

WHAT (*2*) MEANS

Sometimes you may see the OBSOL DAYS and/or the WARN DAYS field contain the
marker (*2*).  This means that the obsolescence days and warning days may have
different values depending on the exact way that the user logs on.  For more
information on this, see the discussion on "WHAT (*2*) MEANS" in the chapter of
the #207 report.


#301. Users with SM or PM capability ``contents`report
#301. Users with SM or PM capability

SM and PM are the two most powerful capabilities that a user can have.  With
either one of them, he can do anything to any object -- database, file, user,
group, etc.  -- on the system.  Naturally, these capabilities should be very
carefully controlled.

Section #301 shows you all users that have either SM or PM.  This includes

   * those users who actually have SM or PM;

   * those users who may not have SM or PM, but are Account Managers (AM) of
     accounts that have SM or PM (they can easily give themselves SM or PM);
     and

   * those users who don't have SM or PM, but have Write or Save access to
     groups in their accounts that have PM capability.  Any user with Write or
     Save access to a PM group can get PM capability.

A sample such report might look like:

User JACK    .AP       has PM
User MGR     .AP       is AM of account with PM
User MANAGER .BXUTIL   has SM and PM
User PETE    .DEV      has write access to PM group OBJ

All of the above should be self-explanatory:

  * JACK.AP actually has PM capability;

  * MGR.AP is AM of the AP account, which has PM capability;

  * MANAGER.BXUTIL has both SM and PM capabilities;

  * PETE.DEV doesn't have PM, but he has write (or save) access to the OBJ.DEV
    group, which does have PM -- thus, he can obtain PM whenever he wants to.

HOW TO FIX THESE PROBLEMS

Some of the users listed should indeed have SM and PM; after all, MANAGER.SYS
must always have SM, and many systems and vendor accounts require PM to run.
However, you may well find many users who have absolutely no need for SM and PM
(in our experience, virtually every site has such users).  For them, we
recommend that you:

   * Take away SM and/or PM from them;

   * If they're AMs of SM/PM accounts, take away AM from them or take away
     SM/PM from their accounts;

   * If they have write or save access to PM groups, take away PM from those
     groups or (better) restrict Write/Save access to those groups.  A command
     such as:

:ALTGROUP OBJ.DEV;ACCESS=(R,X,L:AC)

     permits only Read, eXecute, and Lock access to this group to account
     users; only the account (or system) manager can write or save to this
     group.


#302. Users with OP capability ``contents`report
#302. Users with OP capability

As we discussed in the "PASSWORDLESS USERS WITH OP CAPABILITY" section, users
with OP capability have a surprising amount of power.  An OP user can :STORE
and :RESTORE any file in the system; thus, indirectly, he can read and write
any file in the system.

Section #302 shows you users with OP capability, as well as users who don't
actually have OP but are Account Managers (AM) of accounts that have OP
capability.  A sample output might look like:

User SALMON  .CHASE    has OP
User JOHN    .HARLAN   is AM of account with OP

Armed with this information, you can determine exactly which users really need
OP and take this potentially dangerous capability from all those who don't
really need it.


#303. Job streams that contain embedded passwords ``contents`report
#303. Job streams that contain embedded passwords

As we discussed before (in our documentation on sections #103 and #204), job
streams with embedded passwords are dangerous to your system security for two
reasons:

   * They might be read by unauthorized people who'll see the passwords right
     there in the first line.  Even if the stream files aren't
     globally-readable, they may still be readable by too many people (e.g.
     everybody in a particular account) or might be visible in printouts.

   * Equally importantly, embedded passwords are a powerful disincentive to
     changing passwords periodically.  Even though you know you should change
     passwords frequently, that's very hard (almost impossible) to do if they
     may be embedded in dozens or hundreds of job streams -- especially if
     you're not certain exactly which job streams those are!

This section #303 report catches all such jobs with embedded passwords; with it
you can:

   * Find embedded passwords that, though not readable by everybody, are still
     readable by too many people.

   * Know which job streams you must change when you change a particular
     password.

   * Know which job streams you should edit if you've decided to use a program
     that doesn't require you to have embedded passwords.  STREAMX users note:
     STREAMX (by default) allows you to leave old, incorrect passwords in the
     job -- it will automatically insert the correct ones at STREAM-time.

A sample listing might say:

----FILENAME-----  CONTAINS PASSWORDS OF   READABLE    OBJECT
                   USER/ACCOUNT/GROUP      BY:         HAS CAPS:

AP010J.JOB.AP         User  MGR    .AP     *AC* (*3*)  AM
AP010J.JOB.AP        Group  DATA   .AP     *AC* (*3*)
COMP55.DAVE.DEV       User  DAVE   .DEV    *AC*
TESTJOB.JOB.PROD   Account          PROD   GU
REMJOB.JOB.SYS        User  MANAGER.PROD               [sysb]

This is mostly self-explanatory: the filename, the object (logon account, group
or user) whose passwords are embedded, who the file is readable by, and the
object's capabilities.

Note, however, the "*AC* (*3*)" entry for AP010J.JOB.AP.  This indicates that
the file is apparently readable only by people signed on to the JOB group
(access mask GU); however, since the JOB group has no password, anybody in the
AP account can sign on to it, read the AP010J.JOB.AP file, and see the MGR.AP
passwords!

If this is the case, you may want to add a password to the JOB group or
:ALTGROUP it so that only people with AM capability (or perhaps AL or GL) can
read files inside it.

In general, restricting group access to group users only doesn't do much good
-- in fact, is the same as allowing access to all users in the account -- if
the group has no password.

In addition to embedded "!JOB" passwords, report #303 also shows you job
streams with embedded "!REMOTE HELLO" passwords.  Since VEAUDIT has no way to
determine the capabilities of a user on a remote system, it shows the
environment ID (which is by default the nodename) of the remote system instead
(in brackets, i.e.  "[sysb]" in the example above).

#304. Groups with PM capability that don't need it

In general, you should have as few PM groups (or users or accounts) on your
system as possible.  A group needs PM only if there are PM programs (or SL
files) inside it.  If there are no such files, then you can safely remove PM
from the group; that way, nobody will be able to build PM programs in the group
later that might endanger your system security.

The section #304 report shows you exactly those groups.  For instance, it might
say:

Group DATA  .DEV   has PM capability BUT NO PROGRAMS THAT USE PM
Group TEST  .GL    has PM capability BUT NO PROGRAMS THAT USE PM

Since the groups are known not to have any PM programs (or SL files) in them,
it's perfectly safe for you to :ALTGROUP them to remove PM capability.


#305. Users with AM capability ``contents`report
#305. Users with AM capability

AM capability gives you full control over your account.  It lets you do
anything to any file in the account, add/change/delete users and groups, etc.
Every account normally has at least one AM user; however, it often happens that
your system ends up having many more AM users than it really needs.

Especially in sensitive accounts, you may want to make sure that as few users
as possible have AM; even if you trust your users, the more people have a
particular capability, the more likely it is to be abused (even accidentally).

The section #305 report shows you all the AM users on your system, e.g.:

USER    .ACCOUNT                      ACCOUNT CAPABILITIES

JACK    .DEV     NO USER PASSWORD     SM,OP,AM,AL,GL,ND,SF,IA,BA
MANAGER .DEV                          SM,OP,AM,AL,GL,...

Note that we flag users who don't have user-level or SECURITY passwords (even
if they have account passwords); you may want to set up passwords for these
users, since otherwise anybody who can sign on to that account can get AM
capability.

If you're a SECURITY user, you might see messages that say "!!!NO USER PASSWORD
IN BATCH!!!" or "Passwordless access as SECURITY user ..." -- see the Section
#101 documentation (or the chapter on VEAUDIT And SECURITY Passwords) for more
information on this.

#306. Users protected only by account passwords

An account password is better than no password at all, but it may often not be
sufficient.  If you have several users using the same account, all of them will
know the same password, so it will be of no use for protecting them from each
other.  More importantly, the more people know a secret, the quicker it'll
spread -- a password shared among twenty people isn't much of a password.

The section #306 report shows which users have account passwords but not user
passwords (either MPE or SECURITY).  For instance, it might say:

USER    .ACCOUNT                                 CAPABILITIES

ALICE   .AP        has no user-level password    AM
ANNE    .AP        has no user-level password
MGR     .CONTLIB   has no user-level password    SM,PM,OP

Note that for each user we find, we show whether or not he has SM, PM, OP, and
AM capabilities.

This report shows only those users who lack user passwords but do have account
passwords.  Users who have no passwords at all are reported in section #201
(and also sections #101 and #106 for passwordless users with SM, PM or OP
capability).

If you use SECURITY, we will obviously not report users who are protected by
SECURITY passwords.

However, if the users are imperfectly protected (because you don't use
$BATCH-VEPROFILE or because you have passwordless SECURITY users), we'll report
this much as we would on section #101 -- we might say "no user-level password
in batch" or "Passwordless logon allowed as SECURITY user...".

For more information on this, see the documentation in section #101 or the
VEAUDIT And SECURITY Passwords chapter below.

#401. Globally-writable (including :RELEASEd) files

Files that can be written to by anybody -- which incidentally means that they
can be purged by anybody -- are often security problems.

Sometimes they may be appropriate, but often they're files that were
inadvertently :RELEASEd or put into improperly secured groups; since MPE gives
you no easy way of finding all such files, there could be hundreds (or
thousands) of them on your system without your even knowing it.  This is
especially true since it's so easy to :RELEASE a file and then forget to secure
it.

Section #401 shows you all such globally-writable files, e.g.

FILE    .GROUP.ACCOUNT  CODE  SIZE  TYP    EOF FLIMIT

MAINDATA.DATA .AP       KSAM  406B  FA  103357 130000  RELEASED
TESTPROG.PUB  .AP       PROG  128W  FB     127    127  IN W:ANY GROUP
FDATA7  .TEST .AP             246B  FA   23307  27500  ACD ALLOWS W:@.@

The output shows you the filename, its filecode, record size, file type (just
as in :LISTF...,2), end-of-file and file limit.  It also indicates whether the
file is globally-writable because it's :RELEASEd or because it's in a group
(and account) that allows WRITE access to anybody.

You should look at the files and see whether they really need to be writable by
anybody.  If not, you should

   * :SECURE the :RELEASEd files,

   * :ALTSEC the files whose ACDs (Access Control Definitions) allow Write
     access to @.@, and

   * :ALTGROUP the groups in which the other files reside to restrict write
     access to them (or move the files to better-protected groups).


#402. Privileged (PM) programs ``contents`report
#402. Privileged (PM) programs

A privileged program -- one that was :PREPed with CAP=PM -- can do anything it
wants to your system.  It can read or write any file, look at or change the
system directory, etc.  Needless to say, privileged programs should be very
carefully written so they don't endanger your system security (or, for that
matter, crash your system).

There are very many privileged programs that are perfectly all right.  Most of
HP's programs in PUB.SYS use PM capability; VEAUDIT does too, as do many of
VESOFT's other programs.  Many other independent vendors have very useful (and
quite secure) privileged programs that are no threat to your system security.

However, you may still want to monitor privileged programs, especially ones
that are not in a recognized vendor account.  If you find a privileged program
in your DEV account, you might be rightly suspicious.

Section #402 shows you all your privileged programs, e.g.

FILE .GROUP .ACCOUNT   LAST ACC  CREATE    READABLE WRITABLE RUNNABLE
                       DATE      DATE      BY       BY       BY

PX7  .JACK  .DEV      10 SEP 88  5 JAN 88  CR       CR       AC (*1*)

This shows each file, when it was last accessed, when it was created, and who
can read it, write to it or run it.  If a program file has an ACD (Access
Control Definition), the users allowed to read it, write it or execute it will
be shown; otherwise, the user classes (ANY, AC, AL, GU, GL or CR) will be
shown.  You can review this and see if anything looks improper.

The only unusual thing here is that sometimes your READABLE BY, WRITABLE BY or
RUNNABLE BY column will say "AC (*1*)".  This means that, although access is
theoretically restricted to "GU" (Group User only), in practice anybody in the
account can access the file since the group has no password.  In this case, all
that any user in the DEV account has to do is to sign on into the group JACK
and then he'll be able to run PX7.

Note that PM programs can only be run if they reside in groups that have PM
capability.  The best way to protect your system against unauthorized PM
programs is to minimize the number of PM groups you have.

Also note that we will, in addition to reporting privileged programs, also
report SL files that contain privileged segments.


#403. "hidden" file listing``contents`report`hfs`news
#403. "hidden" file listing

This report displays a complete listing of the files and directory structure of
"hidden" files on a POSIX system.

By "hidden" we mean files that are not displayed by MPE's :LISTF command.  Such
files are visible using MPE's :LISTFILE command, as well as using MPEX's %LISTF
command.

MPE's :LISTF command fails to display files that are not directly inside MPE
Groups, as well as files whose names don't start with alphabetic characters,
filenames that contain non-alphanumeric or lower-case characters or filenames
longer than 8 characters.

Inclusion of a file within this report certainly does not mean that the file
represents a security problem, this report is intended as an aid to system
management.  This report is not available on non-POSIX systems.


#801. Concise directory listing ``contents`report
#801. Concise directory listing

One of the things that MPE doesn't give you is a way to quickly see all the
users, accounts and groups that you have.  MPE's LISTACCT/LISTUSER/LISTGROUP
output is so huge and badly-formatted as to be unreadable.  Imagine scanning
such a listing of your whole system!

Section #801 shows you your system directory with one user, account, or group
per line.  It shows all the security-related information on this line; although
some things like the disc space limit, CPU time count, etc.  are not shown, the
really important things are, including passwords, home groups, access masks,
and capabilities.

A sample report might look like:

OBJECT           PASS-   HOME  -----ACCESS MATRIX----- CAPABILITIES
                 WORD    GROUP R   A   W   L   X   S

Account      AP  BANANA        ANY AC  AC  AC  ANY     AM,AL,GL,...
   User BILL.AP  TTELWEH PUB                           ND,SF,IA,BA
   User DAVE.AP  ******  PUB                           AM,ND,SF,IA,BA
  Group DATA.AP  ------        ANY AC  AC  AC  GU* AC  IA,BA,PH,DS

Everything here should be more or less self-explanatory, except:

   * If an account, user or group has no password, the password field is set to
     "$$$$$$$$", "********" or "--------", respectively.  This should make it
     easier for you to spot passwordless objects.

   * If a group allows access to AL and GU users, this gets shown as "GU*"; if
     it allows access to AL and GL user, it gets shown as "GL*".  We do this to
     save space.


VEAUDITSHOWPASS JCW, triggers showing passwords on report #801
that by default passwords are not actually shown in this report (for
security reasons).  If you want to see the passwords, just say

:SETJCW VEAUDITSHOWPASS=1

before running VEAUDIT.  (Even if you tell VEAUDIT to do the report in batch,
it's enough for you to do the :SETJCW in your session.)

If you do not do this, VEAUDIT will print "notshown" in place of all the
passwords in the report.  Passwordless users/accounts/groups will still be
shown as "********", "$$$$$$$$" and "--------".


#802. SECURITY user listing ``contents`report
#802. SECURITY user listing

Section #802 shows you all the SECURITY users that you have configured on your
system.  You can glance over this list to see if all the users really belong
there, if there are any that are configured with the wrong
time-of-day/day-of-week/terminal access restrictions, when various users were
last logged on to, etc.

A sample report might look like (see the SECURITY User Manual for more
information on what each of the user attributes we output really means):

               SECURITY PASSWORDS?
               V  LOGON    CHANGED  --DAYS-- ---TIMES---  MENU FILE

JOE,CLERK.AP   Y  88/04/17 88/04/14 MON-FRI   9 AM- 6 PM  MENU.PUB.AP
               terminals: 31 32 33 34 35
MARY,CLERK.AP     88/05/13 88/05/04 MON-FRI   8 AM- 5 PM  MENU.PUB.AP
               *** father profile: MARY    ,USER    .GL

For each user, we show:

   * Whether or not the user has SECURITY passwords -- Y if he does, N if he
     doesn't, A if the user has never signed on but was configured to be
     prompted for the correct values of his passwords when he first signs on.

   * The date on which the user last logged on.

   * The date on which the user's passwords were last changed.

   * The days of week on which the user's allowed to sign on (blank if the user
     can sign on any day).

   * The times of day during which the user's allowed to sign on (blank if the
     user can sign on at any time).

   * The menu file which the user sees whenever he signs on (blank if no menu
     file).

   * The user's real name, as specified when the user was added to SECURITY; if
     this is an inheriting user, the user's real name from the parent profile
     will be printed (not shown on this example).

   * If the user has any terminal restrictions, we show them on a separate line
     (prefixed by "terminals:").

   * If the user inherits his SECURITY passwords from another user profile, we
     show the session, user, and account name of the parent profile on a
     separate line (prefixed by "*** father profile:").


VEAUDITSHOWUF, JCW ``news`user`fields`show
VEAUDITSHOWUF, JCW
default, this sectioon does not show $USER-FIELD entries.  If you want to
see the $USER-FIELD entries set for each profile, simply type

:SETJCW VEAUDITSHOWUF=1

before you run VEAUDIT (even if you tell VEAUDIT to do the report in batch,
it's enough for you to do the :SETJCW in your session.)

Although you could get a similar listing from SECURITY's LISTUSERS entry point,
we decided that VEAUDIT should show it to you as well so that you could get all
the auditing information you need from one place.  Note that this section of
the report also shows you the last logon date and the last password change
date, which LISTUSERS doesn't.


#803. Recent MPE directory changes ``contents`report
#803. Recent MPE directory changes

Sometimes it's quite important to see what changes have been made to your
system security structure recently.  Once you've made sure your system is
fairly secure, you want to be able to pay particularly close attention to
things that have changed since the last time you've surveyed it.

This is especially so since you, as a System Manager, share directory
maintenance with your Account Managers.  They can add, change, and delete users
and groups in their own accounts without consulting you; who knows what they've
been up to? Normally, MPE builds an AM user in every account -- they can do a
lot of damage to the security of their own accounts if not properly controlled.

Section #803 of the VEAUDIT report shows you recent changes that have been made
to your MPE users, accounts and groups in the past 30 days (of course, the 30
is just a default -- see below on information about how to change it).  For
instance, a sample report might look like:

Account        ALPHA1    DELETED  10 NOV 88  11 NOV 88

Account        BACKUP    CHANGED  15 NOV 88  17 NOV 88  added *OP*
  Group DATA  .BACKUP    ADDED    15 NOV 88  17 NOV 88
   User JOHN  .BACKUP    ADDED    25 NOV 88  26 NOV 88  added *PM*

This shows:

   * Which accounts, users and groups have been deleted.

   * Which accounts, users and groups have been added.  If the added
     account/user/group has SM, PM, OP or AM capability, the report shows this.
     (It doesn't show the other capabilities since they're usually not
     overwhelmingly important -- you can see them, anyway, using MPE's
     LISTACCT/LISTUSER/LISTGROUP.)

   * Which accounts, users and groups have had their capabilities changed.  The
     report also shows which capabilities have been added and/or deleted,
     highlighting SM, PM, OP or AM.  (Unlike the display for the added users,
     all capabilities that have been added or deleted are indicated.)

   * When the changes took place.  Unfortunately (as we will discuss shortly),
     we can't tell you the exact day on which the changes were made, so we show
     the date range (e.g.  15 NOV 88 through 17 NOV 88) during which the
     changes must have been performed.

This can give you a good quick survey of changes made to your system directory.
Of course, you must still look carefully at the other sections (especially the
ones that show critical problems, like sections #1xx); however, this section
can prove to be a useful additional reference.

How does VEAUDIT know when a user, account or group was added, changed or
deleted? The MPE system directory doesn't keep track of this information; how
can VEAUDIT find it out?

The first time that VEAUDIT is run on your system, it saves the state of the
directory in a special internal file.  Every time VEAUDIT is run after that, it
finds all the differences between the current state and the saved state and
updates the saved state to reflect them; it also marks the saved copy to
indicate when the last change to it was seen.

The more often VEAUDIT is run, the more precisely it can tell you when a change
was made.  If you last ran VEAUDIT on May 10th and are running it again on May
20th, any changes that VEAUDIT detects can only be reported as "between May
10th and May 20th"; if you run it more frequently (e.g.  every night), VEAUDIT
might be able to show you the exact date of the change plus or minus a day.

Naturally, you might not want to output the whole VEAUDIT report every night --
we provide you with a task that just updates our save files without generating
any output.  This task (named AUDITC) runs under the BACKG background job; to
start it, simply do

%VEAUDIT BACKG STARTJOB        (* If it's not already running *)
%VEAUDIT BACKG START,AUDITC

(please see %BACKG in the "MPEX Commands section of the MPEX User Manual for
details).  By default, it will then run every night at 2:00 A.M., but you can
configure this to any time you wish (again, see the %BACKG documentation for
details).  We encourage you to execute AUDITC every night, by leaving it
"started" in the BACKG job and keeping the BACKG job running all the time.


VEAUDITDIRCHGDAYS, JCW ``directory`change`days
VEAUDITDIRCHGDAYS, JCW
default, this section shows you all the changes made in the last 30 days;
you can change this number by saying

:SETJCW VEAUDITDIRCHGDAYS=60   << or whatever >>

(even if you tell VEAUDIT to do the report in batch, it's enough for you to do
the :SETJCW in your session.)

Note that this is intended to show what has been done, not who did it.  The MPE
system directory does not keep track of who created a particular user, account
or group, so there's really no way for us to show you this information.  If
you're really interested in this, your best bet is to minimize the number of SM
and AM users (see the report's sections #101 and #301), and then hold each
account's AM accountable for changes made within his account.


#804. Recent SECURITY user changes ``contents`report
#804. Recent SECURITY user changes

Just as section #803 shows you all the recent MPE directory changes, so this
section shows you all the recent changes to SECURITY profiles (default is to
show changes made in the last 30 days).  For example, this report might say

MARSHALL,MGR .PAYROLL    DELETED  01 JAN 90  03 JAN 90
TANEY   ,MGR .PAYROLL    ADDED    08 JAN 90  09 JAN 90
STORY   ,USER.PAYROLL    CHANGED  08 JAN 90  09 JAN 90
                                    *REMOVED SECURITY PASSWORDS*

This shows:

   * Which users were deleted.

   * Which users were added (with a special note if the user was added without
     SECURITY passwords).

   * Which users had their SECURITY passwords removed (by running
     MAIN.PUB.VESOFT,CHANGE and setting the "ask SECURITY passwords" field to
     NO).

     Other changes (e.g.  password changes, terminal restriction changes, etc.)
     are not indicated because we feel that they would just clutter up the
     report without giving you much important security information.  If you
     want to see the current settings of the various SECURITY user attributes
     (terminal/time-of-day/day-of-week restrictions, menu file, etc.), use the
     LISTUSERS entry point of MAIN.PUB.VESOFT.

   * When the changes took place.  As we discuss in the documentation for
     section #803, we can't tell you the exact day on which the changes were
     made, so we show the date range (e.g.  15 NOV 88 through 17 NOV 88) during
     which the changes must have been performed.

Just like the #803 section (which shows changes in the MPE directory), this
section's output is most precise when you run the AUDITC task under the BACKG
job as often as possible (see the discussion on #803 for more information).  We
encourage you to execute AUDITC every night, by leaving it "started" in the
BACKG job and keeping the BACKG job running all the time.


VEAUDITSECCHGDAYS, JCW ``SECURITY`change`days
VEAUDITSECCHGDAYS, JCW
default, this section shows you all the changes made in the last 30 days;
you can change this number by saying

:SETJCW VEAUDITSECCHGDAYS=60   << or whatever >>

(Even if you tell VEAUDIT to do the report in batch, it's enough for you to do
the :SETJCW in your session.)


#805. UDC files set on the system ``contents`report
#805. UDC files set on the system

MPE doesn't give you a way of determine exactly which UDC files are set for
which users in the system -- information that can be quite relevant to your
system security and your operations.

VEAUDIT's #805 section prints you a report that might look like:

System              LOGONUDC.PUB.VESOFT STRMUDCX.PUB.VESOFT MPEXUDC.PUB.VESOFT

Account AP          APUDC.PUB.AP
   User JACK.AP     TESTUDC1.JACK.AP AUXUDC.OPER.PROD
                     MYUDC.PUB.AP
   User TEST.AP     AUXUDC.OPER.PROD

This shows information on all the system, account, and user-level UDC files
that are set up on the system and whom they are set up for.


#806. Contents of SECURCON.DATA ``contents`report`news
#806. Contents of SECURCON.DATA

Section #806 lists the contents of the SECURITY configuration file
SECURCON.DATA at the time the VEAUDIT report is created.  For detailed
information about the $keywords contained in this file, please see the
SECURITY User Manual.

Note that the $PASS keyword in the SECURCON file contains your actual terminal
(and other special) passwords; in this report, the passwords are replaced with
a string of Xs.

VEAUDIT's #806 section prints you a report that might look like:

$VEPROFILE @.@

$LOG-LOGON ON

$MPE-OBSOL @.@
   $MPE-OBS-DAYS 30
   $MPE-WARN-DAYS 0
   $MPE-OBS-PASSCHG ON
   $MPE-WARN-PASSCHG OFF
$MPE-PASSHIST-DAYS 90

$BATCH-VEPROFILE OFF

$PASS "XXXXXXXX" "TERMINAL PASSWORD" LDEV=20
$PASS "XXXXXXX"  "TERMINAL PASSWORD" LDEV=61
$PASS "XXXXXX"   "TERMINAL PASSWORD" LDEV=72


#807. Contents of STREAMX.DATA ``contents`report`news
#807. Contents of STREAMX.DATA

Section #807 lists the contents of the STREAMX configuration file STREAMX.DATA
at the time the VEAUDIT report is created.  In addition to STREAMX
configuration options, this file also contains configuration options for the
WITHCAPS and CHLOGON commands (which can be used in MPEX, SECURITY logon menus,
and STREAMX).  For detailed information about the $keywords contained in this
file, please see the  SECURITY User Manual.

VEAUDIT's #807 section prints you a report that might look like:

$EMBED-PASS-FORBID   @.@   @.@.@   @.@

$NOPASS   @,STARTUP.SYS   @.STARTUP.SYS   @.@
$NOPASS   OPERATOR.SYS    @.JOB.SYS       @.@

$NO-FILE-SEC-CHECK   OPERATOR.SYS   @.JOB.SYS

$CHLOGON-PERMIT KENT,OPERATOR.SYS  BOOTH.SMCMD.SYS  SUPERMAN,MANAGER.SYS

$WITHCAPS-PERMIT   OPERATOR.SYS   @.SMCMD.SYS   "SM"


#808. Contents of HELLO.DATA ``contents`report`news
#808. Contents of HELLO.DATA

Section #808 lists the contents of the HELLO task configuration file HELLO.DATA
at the time the VEAUDIT report is created.

VEAUDIT's #808 section prints you a report that might look like:

(******* HELLO EDITS *******)

$CHANGE  HI        HELLO

(******* HELLO ABBREVIATIONS *******)

$HELLO   VV        VLADIMIR,MANAGER.TECH,VLADIMIR
$HELLO   EUGENE    EUGENE,MANAGER.VESOFT,WORK;HIPRI
$HELLO   EMBEDDED  ABC/,XYZ/.HIJ/,JHB/

(******* CONFIGURATION *******)

$PEUTIL     allow-sm
$NOPARM     -1
$TIMEOUT    10
$CONFIG     session   refuse  @.noway
$CONFIG     timeout   allow
$CONFIG     backup    refuse
$CONFIG     network   check   @,@.@,@

$CONFIG     network   allow serge,manager.tech,serge


VEAUDIT and SECURITY/3000 passwords ``contents
VEAUDIT and SECURITY/3000 passwords


SECURITY: password protection
, VEAUDIT must find out if an MPE user is protected by a password.
Checking for an MPE password is easy (just look in the system directory) -- but
what about SECURITY passwords? How can one determine whether or not an MPE user
is protected by a SECURITY password?

Because SECURITY gives you many more powerful features than MPE password
security (e.g.  session name security, wildcarded user profiles that apply to
multiple users, etc.), this is not as straightforward a task; and, to
understand VEAUDIT's output, you must understand how VEAUDIT figures this out.
Although you can find this out by reading the SECURITY User Manual, we've
decided to summarize this issue here for your benefit.


VEPROFILE, SECURITY keyword
$VEPROFILE, SECURITY keyword
passwords can only apply to those users who you've protected with the
$VEPROFILE keyword in SECURCON.DATA.VESOFT (the SECURITY configuration file).
If SECURCON.DATA.VESOFT file has a line such as

$VEPROFILE @.PROD @.DEV

then whenever somebody signs on to the PROD or DEV account, SECURITY will try
to find a User Profile for him in the database.

If a user protected by $VEPROFILE does not have a SECURITY user profile, the
user will not be allowed to sign on.  All $VEPROFILE-protected users must have
SECURITY user profiles.

It is this SECURITY user profile -- actually, a record in a SECURITY database
that has been added by the account/system manager using :RUN
MAIN.PUB.VESOFT,ADD -- that contains the user's SECURITY passwords.  For
instance, if the system manager uses MAIN.PUB.VESOFT,ADD to add the user
profiles (passwords entered by user!)

JACK,CLERK.PROD   with password "WHOPPER"
@,MGR.PROD        with password "PAINLESS"
SAM,@.PROD        with password "CARRIE5"

then the only logons that will be permitted to the PROD account are
JACK,CLERK.PROD, any session name with MGR.PROD, and any user ID in PROD with
session name SAM.

Even if no user in the PROD account has an MPE password, the account is still
well-protected -- JACK,CLERK.PROD, @,MGR.PROD, and SAM,@.PROD have SECURITY
passwords, and all other MPE user IDs can't be signed on to at all because they
have no corresponding SECURITY user profiles.

Thus, as long as:

   * a user is protected by $VEPROFILE and

   * all SECURITY user profiles that can be used to sign on to this user ID
     have a SECURITY password,

then that user is password-protected by SECURITY.  You could put an MPE
password on the user, too; however, the SECURITY password should be enough.

Note, however, that when a system manager or account manager configures a user
profile, he can configure it without a SECURITY password.  (When
MAIN.PUB.VESOFT,ADD asks him whether this user is to have SECURITY passwords,
the account or system manager can simply say "NO".) If this is so, then that
user is not password-protected by SECURITY.

For instance, say that in the example above, JACK,CLERK.PROD was configured
without SECURITY passwords (and let's say that CLERK.PROD has no MPE password).
VEAUDIT would recognize this and indicate that CLERK.PROD was not
password-protected.  Even if there were twenty other session names configured
for CLERK.PROD (MARY,CLERK.PROD, JANE,CLERK.PROD, etc.), and each one of them
had a SECURITY password, VEAUDIT would still realize that CLERK.PROD was
imperfectly protected.

Similarly, a wildcarded SECURITY user profile (e.g.  SAM,@.PROD, PETE,@.@,
etc.) could be configured without a SECURITY password.  Wildcarded user
profiles are very useful to, for instance, grant the system manager easy access
to all user IDs on the system -- however, if they're configured without
SECURITY passwords, they can be quite dangerous.  VEAUDIT will catch such
unpassworded wildcarded user profiles; for instance, it might output in its
report that:

User CLERK   .PAYROLL  has no password
  Passwordless access as SECURITY user PETE   ,CLERK   .PAYROLL
                                            TESTING,CLERK   .@

This indicates that CLERK.PAYROLL can be accessed without a password by anybody
who signs on as "PETE,CLERK.PAYROLL" or anybody who signs on as
"TESTING,CLERK.PAYROLL" (because of the passwordless user profile for
"TESTING,CLERK.@").  It may very well be that most CLERK.PAYROLL logons do have
SECURITY passwords; however, those two don't, and passwords should be added for
them.

Finally -- in addition to the need to configure the users to be protected with
$VEPROFILE and to make sure that all of them are configured with SECURITY
passwords -- there's the issue of SECURITY AGAINST BATCH LOGONS.  As the
SECURITY User Manual states,

   IF A USER IS PROTECTED USING $VEPROFILE, HE WON'T BE PROMPTED FOR A SECURITY
   PASSWORD IN BATCH.

In other words, protecting a user with $VEPROFILE makes sure that he must
specify his SECURITY password when logging on as a session; however, if a job
stream logs on to that user ID, SECURITY PASSWORDS WILL NOT BE PROMPTED FOR.


BATCH-VEPROFILE, SECURITY keyword
$BATCH-VEPROFILE, SECURITY keyword
course, the reason for this is that there's no-one to prompt for a password
in batch -- when our SECURITY logon UDC runs in the batch job stream, it won't
ask for a password.  If you want to protect the user from unauthorized batch
access, you must configure the $BATCH-VEPROFILE keyword in the
SECURCON.DATA.VESOFT file as well as the $VEPROFILE keyword:

$VEPROFILE @.PROD @.DEV
$BATCH-VEPROFILE @.PROD @.DEV

Then, anybody who wants to submit a job that signs on into the PROD or DEV
accounts will have to submit it using SECURITY's STREAMX program, which will
prompt the submitting user for the SECURITY passwords.  This way, SECURITY
passwords will still be enforced.

If you don't use $BATCH-VEPROFILE, then you must protect all your users with
MPE passwords -- otherwise, passwordless access will be allowed to some of them
in batch.  In this case, VEAUDIT may output something like:

User JACK    .DEV      has no password in batch

This means that JACK.DEV:

   * has no MPE password,

   * is protected by $VEPROFILE (and a SECURITY password) on-line,

   * but is not protected by $BATCH-VEPROFILE in batch.

We recommend that you use $BATCH-VEPROFILE to protect your system against
unauthorized batch access.

Thus, to summarize, there are three possible ways in which a user can be not
password-protected:

   * User has no MPE password and is not covered by a "$VEPROFILE" keyword in
     SECURCON.DATA.VESOFT. Thus, the user has neither MPE nor SECURITY
     passwords.  VEAUDIT shows this as:

User FRANKLIN.PIERCE   has no password

   * User has no MPE password, is covered by "$VEPROFILE", but not covered by
     "$BATCH-VEPROFILE". Thus, the user is open to possible unauthorized access
     in batch.  VEAUDIT shows this as:

User JACK    .DEV      has no password in batch

   * User has no MPE password and is covered by "$VEPROFILE", but can be signed
     on to using a SECURITY profile that has no password. In this case,
     somebody could sign on using that user profile (e.g.  by specifying the
     appropriate session name) and not be prompted for a SECURITY password.
     VEAUDIT shows this as:

User CLERK   .PAYROLL  has no password
  Passwordless access as SECURITY user PETE,CLERK.PAYROLL
                                       TESTING,CLERK.@

Each of these situations is threatening in its own way, and each can be
remedied in the ways we indicated.


Accounting structure maintenance ``contents
Accounting structure maintenance

GENERAL SYNTAX


General syntax ``contents
General syntax

The %VEAUDIT accounting structure maintenance commands operate on MPE account-,
user-, and group-sets -- objects just like MPEX filesets (i.e.  with +s, -s,
and selection conditions), but referring to MPE accounts, users, and groups
rather than files.  Examples of such commands are:

%VEAUDIT ALTACCT @-TEST-DEV(NOT CAP("LG"));CAP=+LG

%VEAUDIT LISTGROUP @.AP+@.PROD(PASSWORD="")

%VEAUDIT COPYUSER @.AP-MGR.AP, =.GL

Notice again the key ingredients of each set -- optional + sets (for combining
more than one set), optional - sets (for excluding sets), and optional
selection conditions (enclosed in parentheses) that can refer to MPE account,
user or group attribute variables, as the case may be.

Note that MPE usersets are substantially different from VESOFT usersets and are
used in different places.


ALTACCT, %VEAUDIT command ``acct`contents
ALTACCT, %VEAUDIT command
ALTUSER, %VEAUDIT command
ALTGROUP, %VEAUDIT command
:   %VEAUDIT ALTACCT  accountset ;altacctparms
          %VEAUDIT ALTUSER  userset    ;altuserparms
          %VEAUDIT ALTGROUP groupset   ;altgroupparms

Examples: %VEAUDIT ALTACCT @(CAP("SM") and PASSWORD=""); PASS=FIRSTP
          %VEAUDIT ALTUSER @.AP+@.GL(HOMEGROUP="DATA"); HOME=NEWDATA
          %VEAUDIT ALTGROUP @.AP+@.GL-PUB.AP; CAP=-PM

Alter the given accountset, userset or groupset to have the given parameters
(which can be any parameters specifiable on the MPE :ALTACCT, :ALTUSER, and
:ALTGROUP commands).

One substantial extension is that you can specify, say, ";CAP=-PM,-SM" to
remove some capabilities (in this case, PM and SM) without affecting any other
capabilities or ";CAP=+UV,+CV,+LG" to add capabilities without affecting the
others.  This lets you alter capabilities without having to re-specify all the
current capabilities (with all the potential for error that this would
involve), which makes the %VEAUDIT ALTxxx commands useful even for
single-object operations.


COPYACCT, %VEAUDIT command ``acct`contents
COPYACCT, %VEAUDIT command
COPYUSER, %VEAUDIT command
COPYGROUP, %VEAUDIT command
:   %VEAUDIT COPYACCT accountset [,targetset]
                   [;OUT=filename]
                   [;ONVS=volume_name]                     (NEW)

          %VEAUDIT COPYGROUP groupset [,targetset]
                   [;OUT=filename]
                   [;ONVS=volume_name]                     (NEW)

          %VEAUDIT COPYUSER userset [,targetset]
                   [;OUT=filename]

Examples: %VEAUDIT COPYACCT @, @; OUT=ACCSTRUC
          %VEAUDIT COPYUSER @.AP-MGR.AP, @.GL
          %VEAUDIT COPYGROUP @.AP, @.APBACKUP

If you don't specify an ;OUT= parameter, this command copies the given
account-set, user-set or group-set into the target-set (target
account/user/group-sets work much like target filesets in MPEX -- see the
"TARGET FILESETS" chapter of the MPEX User Manual for more information).  The
files in an account or in a group are not copied, but if you copy an account,
all of its users and groups are copied.  Of course, passwords, capabilities,
access masks, etc.  are all copied as well.

If you do specify an ;OUT= parameter, no copy actually takes place, but rather
the file specified by ;OUT= is built as an MPE/iX command file that, if
executed, would create the given accounts, users or groups (with all the
relevant parameters).  This can be very useful for rebuilding the accounting
structure after RELOADs or on other machines.  Before, say, :STOREing an
account, you might do a %VEAUDIT COPYACCT ...;OUT=...  of that account and then
store the file together with that account, ready to be used to re-build the
account.  One of the examples given above:

%VEAUDIT COPYACCT @,@;OUT=ACCSTRUC

is very good for saving the entire accounting structure, and

%VEAUDIT COPYACCT MYACCT;OUT=ACCSTRUC

will do the same for a particular account (note that for this application,
you'd typically want the target account to be the same as the source account).

MOVING GROUPS AND ACCOUNTS TO NON-SYSTEM VOLUME SETS


MOVING GROUPS AND ACCOUNTS TO NON-SYSTEM VOLUME SETS``contents`news
MOVING GROUPS AND ACCOUNTS TO NON-SYSTEM VOLUME SETS

The optional ;ONVS= parameter of the COPYACCT and COPYGROUP commands allow you
to specify a non-system volume set to be included in the resulting command
file.  Note that this doesn't actually MOVE your data, it only adds additional
commands to the command file to configure the groups and accounts as being on a
non-system volume.  For example, in order to move the TEST account and each
group in the account to a non-system volume set, you would need to type these
commands:

:HELLO MANAGER.SYS

:RUN MAIN.PUB.VESOFT
%VEAUDIT COPYACCT TEST;OUT=REBUILD;ONVS=YOUR_PRIVATE_VOLUME_NAME

:FILE TAPE;DEV=TAPE
:STORE @.@.TEST;*TAPE;SHOW

:PURGEACCT TEST
:XEQ REBUILD
:RESTORE *TAPE;@.@.TEST;SHOW;DEV=DISC

The command file REBUILD will contain NEWACCT, NEWUSER, NEWGROUP, and ALTGROUP
commands to rebuild TEST account on the volume specified.  On classic systems,
(since the TEST account will be purged), you will need to edit this file to
convert it into a JOB to be streamed.

Note that adding ";ONVS=xxx" to the :ALTGROUP command doesn't actually move the
data.  (In fact, the group remains on the system volume set if there IS any
data in the group -- this command takes effect ONLY when the group is empty).
By :STOREing the files to tape and purging them in the process or purging the
entire group or account afterwards, the command file that we build will be able
to create the new groups on the specified volume set.  The :RESTORE command
will then read the files back from the tape and place them on the non-system
volume set.  We recommend including ;DEV=DISC on the :RESTORE command to remove
any drive specific information from the file labels on the tape.


LISTACCT, %VEAUDIT command ``acct`contents
LISTACCT, %VEAUDIT command
LISTUSER, %VEAUDIT command
LISTGROUP, %VEAUDIT command
:   %VEAUDIT LISTACCT accountset [,outfile]
             [;PASS] [;ALLCAPS] [;FULL]
          %VEAUDIT LISTUSER userset    [,outfile]
             [;PASS] [;ALLCAPS] [;FULL]
          %VEAUDIT LISTGROUP groupset  [,outfile]
             [;PASS] [;ALLCAPS] [;FULL]

Examples: %VEAUDIT LISTACCT @(PASSWORD=""); ALLCAPS
          %VEAUDIT LISTUSER @.@(CAP('SM') or CAP('PM')); PASS; FULL
          %VEAUDIT LISTGROUP @.AP+@.GL+@.PROD,*LP

Lists the attributes of all the accounts, users or groups in the given set.
The big advantages of these commands over MPE's LISTACCT/LISTUSER/LISTGROUP
commands are that selection conditions (and "+" or "-" account/group/user-sets)
are permitted, and output is much more compact (one or two lines rather than
the unwieldy outputs that those commands provide, often over 10 lines).

By default, passwords are not listed; if an object has no password, blanks are
shown in the password field -- if it does, "notshown" is printed in place of
the password.  Specifying ;PASS tells MPEX to print the password (though you
must, of course, have the appropriate capabilities to do this).

A major problem that we faced in designing these commands was making their
output as compact as possible, preferably so as to fit within one line on the
terminal.  We found that the bulk of the really useful information could fit in
these 80 characters, so by default we

   * for accounts and groups, omit the disc space limit, the CPU and connect
     counts and limits, and (for accounts) the local attribute;

   * for accounts and users, show only SM, OP, AM, AL, GL, PM, BA, IA, MR, DS,
     and PH capabilities.

If you specify ;FULL, the disc space limit, CPU and connect count and limits,
and local attributes will be output as well in a 132-character output line.  If
you specify ;ALLCAPS, all user and account capabilities will be output (also in
a 132-character line), but for accounts we will output two lines for each
account (the second line for the capabilities and the first line for all the
other information).

One other important note: the "ACCESS ALLOWED" fields displayed for groups
indicate who is allowed to access files in those groups:

   - ANY = any user;
   - AC = any user in the account;
   - AL = any user in the account who has AL capability;
   - GU = any user signed on to the given group;
   - GL = any user who has GL capability, signed on to the given group;
   - GU* = either GU or AL;
   - GL* = either GL or AL.

Note also that this output may be somewhat different than that shown by MPE's
LISTACCT/LISTUSER/LISTGROUP because it takes into account both the group access
restrictions and the account access restrictions.  Furthermore, some
redundancies are eliminated (e.g.  MPE might show a group as having "ANY,AC,GU"
access, but we'll only show it as "ANY" because once ANY access is given, AC
and GU are irrelevant), and if a particular user class has write access, it is
also shown as having append and lock access (because that's the way the file
system treats it).  We think that our way of displaying the data is more
precise and less confusing.


PURGEACCT, %VEAUDIT command ``acct`contents
PURGEACCT, %VEAUDIT command
PURGEUSER, %VEAUDIT command
PURGEGROUP, %VEAUDIT command
:   %VEAUDIT PURGEACCT accountset [;NOVERIFY] [;QUIET]
          %VEAUDIT PURGEUSER userset    [;NOVERIFY] [;QUIET]
          %VEAUDIT PURGEGROUP groupset  [;NOVERIFY] [;QUIET]

Examples: %VEAUDIT PURGEUSER @ &
             ((CAP("SM") or CAP("PM")) and PASSWORD="")
          %VEAUDIT PURGEGROUP X#@.VESOFT
          %VEAUDIT PURGEGROUP @.PROD (DISCCOUNT=0)

Purges the given accountset, userset or groupset.  By default, shows what
accounts, users or groups are to be purged, and asks you to confirm whether or
not the purges should be done; if you do not confirm, aborts the operation.

If you want to purge the objects without the verification, you can use the
;NOVERIFY keyword; if you also specify the  ;QUIET keyword, the names of the
objects being purged will also not be printed.

Of course, as with all the other commands, you can only perform these commands
if you have the appropriate capabilities (SM for other accounts or users/groups
in other accounts, AM for users/groups in your own account).

These commands are available only to users who use both MPEX and VEAUDIT.


%REPEAT ... %VEAUDIT FORACCTS, VEAUDIT command ``accts`contents
%REPEAT ... %VEAUDIT FORACCTS, VEAUDIT command
%REPEAT ... %VEAUDIT FORUSERS, VEAUDIT command
%REPEAT ... %VEAUDIT FORGROUPS, VEAUDIT command
:   %REPEAT
          %>command1
          %>command2
               ...
          %>commandN
          %VEAUDIT FORACCTS accountset
             or
          %VEAUDIT FORUSERS userset
             or
          %VEAUDIT FORGROUPS groupset

Examples: %REPEAT
          %  COMMENT Copy a file into all groups (except DATA and PUB)
          %  COMMENT in the AP account
          %  :COPY CONTFILE.DATA.AP,CONTFILE.![RGROUP.GROUP].AP
          %VEAUDIT FORGROUPS @.AP-DATA.AP-PUB.AP

Executes a set of MPEX commands on all accounts, users or groups in an
account-/user-/group-set.


RUSER., prefix for user attribute variable
RGROUP., prefix for group attribute variable
RACCT., prefix for account attribute variable
like the file attribute variables of the current file are available in a
%REPEAT ...  %FORFILES construct by saying "![RFILE.attrvar]", so the account,
user, and group attribute variables are available by saying, respectively,
"![RACCT.attrvar]", "![RUSER.attrvar]" or "![RGROUP.attrvar]".


ALTUDC, %VEAUDIT command ``UDCs`contents
ALTUDC, %VEAUDIT command
:   %VEAUDIT ALTUDC  userset; FROM=fromfileset; TO=tofileset

Examples: %VEAUDIT ALTUDC @.@; FROM=LOGONUDC.PUB.SECURITY; &
             TO=LOGONUDC.PUB.VESOFT
          %VEAUDIT ALTUDC MGR.PROD; FROM=@UDC1.UDC.PROD; &
             TO=@UDC2.UDC.PROD
          %VEAUDIT ALTUDC MANAGER.DEV+MANAGER.TEST; &
             FROM=PHUDC.PUB.COGNOS; TO=PHUDC.CATALOG.ROBELLE

Did you ever want to replace one UDC file with another, but you weren't sure
which users (and/or accounts) the old UDC file was currently set for? The
%VEAUDIT ALTUDC command finds all of the users and accounts on your system that
the FROM-fileset is currently :SETCATALOGed for and :SETCATALOGs them to the
TO-fileset!  (If any files in the FROM fileset are :SETCATALOGed at the SYSTEM
level, those will be replaced as well.)

In other words, if the user MGR.PROD currently has the following UDC files set:

   USER UDC CATALOG FILE NAMES:
      MGRUDC1.PUB.PROD

   ACCOUNT UDC CATALOG FILE NAMES:
      ACCTUDC1.PUB.PROD

   SYSTEM UDC CATALOG FILE NAMES:
      LOGONUDC.PUB.VESOFT
      STRMUDCX.PUB.VESOFT
      MPEXUDC.PUB.VESOFT
      SYSUDC1.PUB.SYS

and you issue the command

   %VEAUDIT ALTUDC MGR.PROD; FROM=@1.@.@; TO=@2.=.=

MGR.PROD will then have these UDC files set:

   USER UDC CATALOG FILE NAMES:
      MGRUDC2.PUB.PROD

   ACCOUNT UDC CATALOG FILE NAMES:
      ACCTUDC2.PUB.PROD

   SYSTEM UDC CATALOG FILE NAMES:
      LOGONUDC.PUB.VESOFT
      STRMUDCX.PUB.VESOFT
      MPEXUDC.PUB.VESOFT
      SYSUDC2.PUB.SYS

As you may have noticed, the TO-fileset can contain @s and =s; see the
documentation on the OBJECTFILE(...) function in Appendix for details.

Like the MPE :SETCATALOG command, %VEAUDIT ALTUDC allows users to modify their
own UDCs, AM users to modify any UDCs in their own account, and SM users to
modify any UDC catalog on the system.


LISTUDC, %VEAUDIT command ``UDCs`contents
LISTUDC, %VEAUDIT command
:   %VEAUDIT LISTUDC userset [;FILE=fileset] [;INVERT]

Examples: %VEAUDIT LISTUDC @.@
          %VEAUDIT LISTUDC @.PROD+@.DEV
          %VEAUDIT LISTUDC @.@-@.VESOFT; FILE=@.PUB.VESOFT

Lists the UDC files which are set for each user in a userset (system, account,
and/or user); if you use the ;FILE=fileset option, shows you only those files
which match the fileset.  If you use the ;INVERT keyword, the output is
inverted, and shows the list of all users who have each individual UDC file
SETCATALOGed.


LISTLOG, %VEAUDIT command ``contents
LISTLOG, %VEAUDIT command
:   %VEAUDIT LISTLOG CONSOLE|FCLOSE|LOGON [userset]
                   [ ;BEGIN=[date][,time] ]
                   [ ;END=[date][,time] ]
                   [ ;SORT=field1[:len1][:'DESC']
                         [,field2[:len2][:'DESC']...]
                   [ ;SEARCH=(selectioncondition) ]

Examples: %VEAUDIT LISTLOG LOGON LDEV=27    (* all logons to LDEV 27 *)
          %VEAUDIT LISTLOG LOGON @.@; SEARCH=(ISBADLOGON)
             (* unsuccessful logon attempts *)
          %VEAUDIT LISTLOG LOGON LDEV=MODEM; SEARCH=(ISBADLOGON)
             (* unsuccessful logon attempts on device class MODEM *)
          %VEAUDIT LISTLOG LOGON @.TELESUP; &
             SEARCH=(DATEMONTH(DATE)=5 and (TIME>5PM or TIME<9AM)); &
             BEGIN=05/01/92; END=05/31/92
             (* Logons to TELESUP at night, during May *)

          %VEAUDIT LISTLOG CONSOLE @.@; SORT=JOBNUMBER
             (* console messages/commands, sorted by job number *)
          %VEAUDIT LISTLOG CONSOLE @.@; SEARCH=ISSECMESSAGE
             (* security-related console messages *)
          %VEAUDIT LISTLOG CONSOLE @.@; SEARCH=MESSAGE MATCHES "@Vol@"
             (* console messages related to volumes mounted *)

          %VEAUDIT LISTLOG FCLOSE @.@; SEARCH=(JOBNUMBER=68)
          %VEAUDIT LISTLOG FCLOSE @.PROD; &
             SEARCH=((TIME>5PM or TIME<8AM) and ISSESSION); &
             SORT=LDEVIN
             (* files modified at night, sorted by LDEV of modifier *)
          %VEAUDIT LISTLOG FCLOSE @.@; SEARCH=(FACCOUNT<>ACCOUNT)
             (* files modified by users logged in to other accounts *)
          %VEAUDIT LISTLOG FCLOSE @.@; SEARCH=(F='NL.PUB.VESOFT')
             (* show all FCLOSE records for file 'NL.PUB.VESOFT' *)


CONSOLE, %VEAUDIT LISTLOG keyword
FCLOSE, %VEAUDIT LISTLOG keyword
LOGON, %VEAUDIT LISTLOG keyword
%VEAUDIT LISTLOG command allows users with SM capability to list MPE system
log file records (of course, you must have logging enabled for there to be any
log records to list; please see the HP manuals on System Logging for
information about starting/stopping the various logging options, managing
system logfiles, etc.).  You can generate reports on:

   * CONSOLE log records, including :TELLs, :WARNs, LOGON and LOGOFF messages,
     security violation messages, operator :REPLY requests, device status
     messages, network status messages, etc.  To list all security-related
     console messages generated on 04/01/92:

%VEAUDIT LISTLOG CONSOLE @.@;SEARCH=(ISSECMESSAGE and DATE=04/01/92)

   * FCLOSE log records, which can be used to find out who was accessing which
     files.  To see what files were accessed by job #J233:

%VEAUDIT LISTLOG FCLOSE @.@;SEARCH=(FMTJOB="#J233")

   * LOGON log records.  To see who logged on to LDEV 122:

%VEAUDIT LISTLOG LOGON @.@;SEARCH=(LDEVIN=122)

The userset is limited to data contained in the log records (i.e.  you can't
use things like CAP=SM); however, the FCLOSE and CONSOLE log records are merged
with the appropriate LOGON record (assuming it is in the logfiles you are
reporting on); this allows you to, for example, select FCLOSE records of
everyone who logged on to the SYS account.  If the LOGON record is not in the
logfiles you are reporting on, these fields (jobname, username, ldev, etc.)
will be left blank.


SEARCH=, %VEAUDIT LISTLOG keyword
selection condition can be an arbitrary VESOFT expression (see Appendix for
details), and can include the special "system logfile attribute variables and
functions"  documented below.  For example, to select console log record
messages for all of the :STORE;PROGRESS= messages, you might use the expression

;SEARCH=(MESSAGE MATCHES "STORE OPERATION IS @% COMPLETE")

Be aware, however, that functions like VEUSERINFO return information about the
current attributes of users (and groups, and accounts, etc.); although you can
combine log file variables with these functions, an expression like

;SEARCH=(VEUSERINFO(USER+"."+ACCOUNT).CAP("AM"))

will show you the records for users who currently have "AM" capability, not
necessarily users who had "AM" capability at the time the log record was
written.


SORT=, %VEAUDIT LISTLOG keyword
default, the log file records will be listed in chronological order, but you
may sort the listing on any of the "system logfile attribute variables and
functions" (again, documented below).  Note that whenever you sort by a STRING
you must specify the number of bytes (len1, len2...) that you want to sort by
(otherwise you'll get an error message).


BEGIN=, %VEAUDIT LISTLOG keyword
END=, %VEAUDIT LISTLOG keyword
;BEGIN= and ;END= keywords may be used to limit which logfiles are
examined; if specified, only logfiles that were last modified on or after the
;BEGIN= date,time and on or before the ;END= date,time will be searched.
Although you could accomplish the same thing by using the ;SEARCH= keyword and
the DATE attribute, ;BEGIN= and ;END= are much faster, since they skip over
entire files that don't contain any qualifying records (;SEARCH= tests are
applied to every record of every logfile processed).  Note: if you :RESTORE old
log files to report on them, be sure to use the ;OLDDATE option!


Object attribute variables ``contents
Object attribute variables

The VEAUDIT commands described above let you perform various operations on
objects like accounts, groups and users, and system log file records.  One of
the ways in which we give you a lot of power in dealing with these objects is
by letting you evaluate arbitrary expressions involving various attributes of
these objects.

These "object attribute variables" are useful in a variety of contexts,
including:

   * %VEAUDIT LISTUSER, LISTGROUP, LISTACCT and/or LISTLOG selection
     conditions;

   * the ![RUSER.attrvar], ![RGROUP.attrvar] and ![RACCT.attrvar], constructs
     as used in the %REPEAT ... %VEAUDIT FORUSER, FORGROUPS and/or FORACCTS
     commands (similar to ![RFILE.attrvar] for %REPEAT ...  %FORFILES).

   * in an MPEX EXTENDED FILESET SELECTION using the DIRACCOUNT.attribute and
     DIRGROUP.attribute functions.

   * and virtually anywhere an expression is allowed by using the VEACCTINFO,
     VEUSERINFO and VEGROUPINFO functions (see Appendix for details).

SYSTEM LOG FILE ATTRIBUTE VARIABLES


System log file attributes ``object`contents
System log file attributes

Usable in %VEAUDIT LISTLOG selection conditions; there are three types of
"system log file" attribute variables: LOGON, CONSOLE, and FCLOSE.


LOGON log record attributes
log records
(If the appropriate LOGON record is in the log files being reported on, these
attributes may also be used to select CONSOLE and FCLOSE records.)


DATE, system log file attribute variable ``logon
DATE, system log file attribute variable
               [DATE]    Date of log record


TIME, system log file attribute variable ``logon
TIME, system log file attribute variable
               [TIME]    Time of log record


PIN, system log file attribute variable ``logon
PIN, system log file attribute variable
                [INT]     The pin number of the process that generated the
                              log record


ISSESSION, system log file attribute variable ``logon
ISSESSION, system log file attribute variable
          [BOOL]    TRUE if log record was generated by a session


ISJOB, system log file attribute variable ``logon
ISJOB, system log file attribute variable
              [BOOL]    TRUE if log record was generated by a job


ISSYSTEM, system log file attribute variable ``logon
ISSYSTEM, system log file attribute variable
           [BOOL]    TRUE if log record was generated by a system
                              process


ISBADLOGON, system log file attribute variable ``logon
ISBADLOGON, system log file attribute variable
         [BOOL]    TRUE if log record was generated by an invalid
                              logon attempt (only valid for LOGON records)


JOBNUMBER, system log file attribute variable ``logon
JOBNUMBER, system log file attribute variable
          [INT]     The number of the job or session


FMTJOB, system log file attribute variable ``logon
FMTJOB, system log file attribute variable
             [STR]     Job or session number in #Jnnn/#Snnn format


JSNAME, system log file attribute variable ``logon
JSNAME, system log file attribute variable
             [STR]     The job/session name


USER, system log file attribute variable ``logon
USER, system log file attribute variable
               [STR]     The user name


HGROUP, system log file attribute variable ``logon
HGROUP, system log file attribute variable
             [STR]     The home group name


ACCOUNT, system log file attribute variable ``logon
ACCOUNT, system log file attribute variable
            [STR]     The account name


GROUP, system log file attribute variable ``logon
GROUP, system log file attribute variable
              [STR]     The logon group name


FMTLOGON, system log file attribute variable ``logon
FMTLOGON, system log file attribute variable
           [STR]     Job/session ID, formatted as:
                                JOBNAME,USER.ACCOUNT,GROUP


LDEVIN, system log file attribute variable ``logon
LDEVIN, system log file attribute variable
             [INT]     The device the user was logged on to


LDEV, system log file attribute variable ``logon
LDEV, system log file attribute variable
               [INT]     (Synonym for LDEVIN)


LDEVLIST, system log file attribute variable ``logon
LDEVLIST, system log file attribute variable
           [INT]     The output device for the job or session


QUEUE, system log file attribute variable ``logon
QUEUE, system log file attribute variable
              [STR]     The queue (e.g.  "CS") the job logged onto


CPULIMIT, system log file attribute variable ``logon
CPULIMIT, system log file attribute variable
           [INT]     The CPU limit for this logon (0=unlimited)


INPRI, system log file attribute variable ``logon
INPRI, system log file attribute variable
              [INT]     Job input (;INPRI=) priority


OUTCLASS, system log file attribute variable ``logon
OUTCLASS, system log file attribute variable
           [INT]     The output class (;OUTCLASS=) for the job


LOGONDATE, system log file attribute variable ``logon
LOGONDATE, system log file attribute variable
          [DATE]    date the job or session logged on


LOGONTIME, system log file attribute variable ``logon
LOGONTIME, system log file attribute variable
          [TIME]    time the job or session logged on


FCLOSE log record attributes
(NM and CM) log records


FFILE, system log file attribute variable ``FCLOSE
FFILE, system log file attribute variable
              [STR]     The name of the file that was closed


FGROUP, system log file attribute variable ``FCLOSE
FGROUP, system log file attribute variable
             [STR]     The file's group name


FACCOUNT, system log file attribute variable ``FCLOSE
FACCOUNT, system log file attribute variable
           [STR]     The file's account name


FCREATOR, system log file attribute variable ``FCLOSE
FCREATOR, system log file attribute variable
           [STR]     The file's creator


F, system log file attribute variable ``FCLOSE
F, system log file attribute variable
                  [STR]     Full filename ("file.group.account")


ISDISCFILE, system log file attribute variable ``FCLOSE
ISDISCFILE, system log file attribute variable
         [BOOL]    TRUE if this is a disc file


FCLOSEDISP, system log file attribute variable ``FCLOSE
FCLOSEDISP, system log file attribute variable
         [INT]     The disposition for the file close
                                  0 = unchanged
                                  1 = make perm
                                  2 = make temp
                                  3 = make temp, no rewind
                                  4 = purge
                                  5 = make temp (from perm)


FOPENDOMAIN, system log file attribute variable ``FCLOSE
FOPENDOMAIN, system log file attribute variable
        [INT]     The domain the file was opened in originally
                                  0 = new
                                  1 = old
                                  2 = temp
                                  3 = any (look for temp first, then perm)


FOPENSTATUS, system log file attribute variable ``FCLOSE
FOPENSTATUS, system log file attribute variable
        [INT]     (MPE/iX only) Status that was returned by the
                              FOPEN (See the MPE Intrinsics Reference Manual
                              for details)


CONSOLE log record attributes
log records


ISSECMESSAGE, system log file attribute variable ``CONSOLE
ISSECMESSAGE, system log file attribute variable
       [BOOL]    TRUE if the message is security related (missing
                              account, invalid pass, no home group or "VESOFT
                              SECURITY"...)


ISOPCMD, system log file attribute variable ``CONSOLE
ISOPCMD, system log file attribute variable
            [BOOL]    TRUE if this is an operator command log record


CMD, system log file attribute variable ``CONSOLE
CMD, system log file attribute variable
                [STR]     The full operator command (for ISOPCMD records)


ISOUTPUT, system log file attribute variable ``CONSOLE
ISOUTPUT, system log file attribute variable
           [BOOL]    Opposite of ISOPCMD (i.e.  console messages
                              instead of console commands)


FULLMESSAGE, system log file attribute variable ``CONSOLE
FULLMESSAGE, system log file attribute variable
        [STR]     The full text of the console message
MESSAGE             [STR]     The message only, with "time/jsnum/pin/" removed

MPE ACCOUNT ATTRIBUTE VARIABLES


MPE account attributes ``object`contents
MPE account attributes
RACCT., account attribute prefix

Usable in %VEAUDIT LISTACCT selection conditions, VEACCTINFO('acct').attrvar
expressions, and ![RACCT.attrvar] in a %REPEAT ...  %VEAUDIT FORACCTS
construct.


ACCOUNT, VEACCTINFO attribute
            [STR]     Account name, stripped of trailing blanks.


PASSWORD, VEACCTINFO attribute
           [STR]     Account password, stripped of trailing blanks.


CAPS, VEACCTINFO attribute ``capabilities
CAPS, VEACCTINFO attribute
               [INT]     Capabilities, in WHO intrinsic format.


FMTCAPS, VEACCTINFO attribute ``capabilities
FMTCAPS, VEACCTINFO attribute
            [STR]     Capabilities formatted, as in HPACCTCAPF
                              variable.


CAP(S), VEACCTINFO function ``capabilities
CAP(S), VEACCTINFO function
(S)              [BOOL]    TRUE if the account has the capability indicated
                              by the string S, e.g.  CAP("PM") means "does
                              account have PM capability?"


SECxANY, VEACCTINFO attribute ``security`access
SECxANY, VEACCTINFO attribute
            [BOOL]    TRUE if given access x(R=Read, W=Write, A=Append,
                              L=Lock, X=eXecute) is allowed to ANY.


SECxAC, VEACCTINFO attribute ``security`access
SECxAC, VEACCTINFO attribute
             [BOOL]    TRUE if given access x is allowed to AC (account)
                              users.


MAXPRI, VEACCTINFO attribute ``priority
MAXPRI, VEACCTINFO attribute
             [INT]     Maximum account priority.


LOCATTR, VEACCTINFO attribute ``local`attribute
LOCATTR, VEACCTINFO attribute
            [INT]     Local attribute.


DISCCOUNT, VEACCTINFO attribute ``sectors
DISCCOUNT, VEACCTINFO attribute
          [INT]     Number of sectors of disc space used.


DISCLIMIT, VEACCTINFO attribute ``limit
DISCLIMIT, VEACCTINFO attribute
          [INT]     Maximum number of sectors allowed (;FILES=).


CPUCOUNT, VEACCTINFO attribute
           [INT]     Number of CPU seconds used.


CPULIMIT, VEACCTINFO attribute ``limit
CPULIMIT, VEACCTINFO attribute
           [INT]     Maximum number of CPU seconds allowed (;CPU=).


CONNECTCOUNT, VEACCTINFO attribute
       [INT]     Number of connect minutes used.


CONNECTLIMIT, VEACCTINFO attribute ``limit
CONNECTLIMIT, VEACCTINFO attribute
       [INT]     Maximum number of connect minutes allowed
                              (;CONNECT=).

MPE USER ATTRIBUTE VARIABLES


MPE user attributes ``object`contents
MPE user attributes
RUSER., user attribute prefix

Usable in %VEAUDIT LISTUSER selection conditions,
VEUSERINFO('user.acct').attrvar expressions, ![RUSER.attrvar] in a %REPEAT ...
%VEAUDIT FORUSERS construct, and in the %SEC AUTOLOAD and %SEC OBSMPEPASS
commands.


USER, VEUSERINFO attribute
               [STR]     User name, stripped of trailing blanks.


HOMEGROUP, VEUSERINFO attribute ``group
HOMEGROUP, VEUSERINFO attribute
          [STR]     Home group name, stripped of trailing blanks.


PASSWORD, VEUSERINFO attribute
           [STR]     User password, stripped of trailing blanks.


CAPS, VEUSERINFO attribute ``capabilities
CAPS, VEUSERINFO attribute
               [INT]     Capabilities, in WHO intrinsic format.


FMTCAPS, VEUSERINFO attribute ``capabilities
FMTCAPS, VEUSERINFO attribute
            [STR]     Capabilities formatted, as in HPUSERCAPF
                              variable.


CAP(S), VEUSERINFO function ``capabilities
CAP(S), VEUSERINFO function
(S)              [BOOL]    TRUE if the user has the capability indicated by
                              the string S, e.g.  CAP("PM") means "does user
                              have PM capability?"


MAXPRI, VEUSERINFO attribute ``priority
MAXPRI, VEUSERINFO attribute
             [INT]     Maximum user priority.


LOCATTR, VEUSERINFO attribute ``local`attribute
LOCATTR, VEUSERINFO attribute
            [INT]     Local attribute.


A.xxx, user/account attribute variable
.xxx                         Indicates field "xxx" of the account entry
                              pertaining to this user's account -- e.g.
                              VEUSERINFO("JOE.PROD").A.PASSWORD returns the
                              PROD account's password.

MPE GROUP ATTRIBUTE VARIABLES


MPE group attributes ``object`contents
MPE group attributes
RGROUP., group attribute prefix

Usable in %VEAUDIT LISTGROUP selection conditions,
VEGROUPINFO('group.acct').attrvar expressions, and ![RGROUP.attrvar] in a
%REPEAT ...  %VEAUDIT FORGROUPS construct.


GROUP, VEGROUPINFO attribute
              [STR]     Group name, stripped of trailing blanks.


PASSWORD, VEGROUPINFO attribute
           [STR]     Group password, stripped of trailing blanks.


CAPS, VEGROUPINFO attribute ``capabilities
CAPS, VEGROUPINFO attribute
               [INT]     Capabilities, in WHO intrinsic format.


FMTCAPS, VEGROUPINFO attribute ``capabilities
FMTCAPS, VEGROUPINFO attribute
            [STR]     Capabilities formatted, as in HPGROUPCAPF
                              variable.


CAP(S), VEGROUPINFO function ``capabilities
CAP(S), VEGROUPINFO function
(S)              [BOOL]    TRUE if the group has the capability indicated by
                              the string S, e.g.  CAP("PM") means "does group
                              have PM capability?"


SECxANY, VEGROUPINFO attribute
            [BOOL]    TRUE if given access x(R=Read, W=Write, A=Append,
                              L=Lock, X=eXecute) is allowed to ANY.


SECxAC, VEGROUPINFO attribute
             [BOOL]    TRUE if given access x is allowed to AC (account)
                              users.


SECxAL, VEGROUPINFO attribute
             [BOOL]    TRUE if given access x is allowed to capability
                              AL users.


SECxGU, VEGROUPINFO attribute
             [BOOL]    TRUE if given access x is allowed to GU (group)
                              users.


SECxGL, VEGROUPINFO attribute
             [BOOL]    TRUE if given access x is allowed to capability
                              GL users.


DISCCOUNT, VEGROUPINFO attribute``sectors
DISCCOUNT, VEGROUPINFO attribute
          [INT]     Number of sectors of disc space used.


DISCLIMIT, VEGROUPINFO attribute ``limit
DISCLIMIT, VEGROUPINFO attribute
          [INT]     Maximum number of sectors allowed (;FILES=).


CPUCOUNT, VEGROUPINFO attribute
           [INT]     Number of CPU seconds used.


CPULIMIT, VEGROUPINFO attribute ``limit
CPULIMIT, VEGROUPINFO attribute
           [INT]     Maximum number of CPU seconds allowed (;CPU=).


CONNECTCOUNT, VEGROUPINFO attribute
       [INT]     Number of connect minutes used.


CONNECTLIMIT, VEGROUPINFO attribute ``limit
CONNECTLIMIT, VEGROUPINFO attribute
       [INT]     Maximum number of connect minutes allowed
                              (;CONNECT=).


HOMEVOLUMESET, VEGROUPINFO attribute ``volumeset`news
HOMEVOLUMESET, VEGROUPINFO attribute
      [STR]     Home volume set for the group.


A.xxx, group/account attribute variable
.xxx                         Indicates field "xxx" of the account entry
                              pertaining to this group's account -- e.g.
                              VEGROUPINFO("PUB.PROD").A.PASSWORD returns the
                              PROD account's password.

The following is a list of everything that we believe could be considered an
"incompatibility" with the previous major release of VEAUDIT.  We don't believe
any of these changes should have a major negative impact on you, but we wanted
to make you aware of them.

For more details on any of these features, please see the main entry for that
feature in the VEAUDIT User Manual.

  *  %VEAUDIT ALTUSER/ALTGROUP/ALTACCT ;CAP=

The ALTUSER/ALTGROUP/ALTACCT commands have been enhanced to match MPE's
definition of "+" and "-" capabilities.

If you specify ;CAP=+PM,IA, it will be treated as ;CAP=+PM,+IA (the "+" does
not need to be repeated).  Similarly, if you specify ;CAP=-PH,UV,MR,DS, then
all of these capabilities will be removed.

If you specified an unsigned capability using prior version of our software, we
would have ignored any "+caps" and "-caps" and only set the capabilities
specified without a sign.  Now we consider the sign of an unsigned capability
to be the same as that of the last specified sign.

                       *** END OF VEAUDIT DOCUMENT ***