[Info-vax] VMS and MFA?

[Dave Froble]

On 8/20/2020 12:45 PM, geze... at rlgsc.com wrote:
> On Thursday, August 20, 2020 at 12:02:21 PM UTC-4, Stephen Hoffman wrote:
>> On 2020-08-20 07:12:01 +0000, Dave Froble said:
>>
>>> I'm aware there are multiple methods to achieve desired results. But
>>> I'm curious, why get into the complexity of rightslist entries?
>> That's using OpenVMS enforcement for access.
>>> A captive account, with a menu of possible apps to run, pretty much
>>> locks a user into just those apps. Of course a menu utility that
>>> allows for custom menus for each user makes this simple. If a user
>>> somehow gets out of the allowed apps, being captive, the process is
>>> killed.
>> The difference here is that OpenVMS enforces the access, in addition to
>> whatever enforcement logic is in the captive command procedure.
>>
>> This approach likely on the assumption that a captive command
>> procedure—any app, for that matter—might be vulnerable.
>>
>> And it means that the site folks don't have to mess with the DCL
>> procedure to change access, and don't need to implement their own
>> user-to-access mapping.
>>
>> Sandboxes use a similar approach, though those can permit or can block
>> APIs beyond what OpenVMS considers security-relevant objects. (As
>> differentiated from OOP.)
>>
>> In a way of consideration around isolation and permissions, sandboxes
>> are to identifiers as identifiers are to UIC-based protections.
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
> Dave,
>
> Hoff stated what I did not make explicit.
>
> The rightslist identifiers controlled the display of the menu items. However, that was not the end of the configuration. The specific executables in the menu items were similarly protected with only the identifier granting execute access.
>
> Of course, the creation, granting, and revocation of identifiers was, from the perspective of day-to-day use completely encapsulated in a series of command procedures only usable by the designated supervisors. Besides the systems manager, no individuals had access to DCL outside of a captive command procedure.
>
> - Bob Gezelter, http://www.rlgsc.com
>

That's how our customers are set up.  Everybody, including the system 
manager, is in captive processes.

Perhaps "system manager" is a bit much, all the selected individual(s) 
can do is add or delete user accounts.  That's all tightly controlled.

I'm guessing your approach is similar to Steve's desire for "everything" 
to be OS provided.  My approach was (many years ago) to design and 
implement a menu utility that controls all access for the captive users. 
  I'd believe that it's much more inclusive and capable than any OS 
capability.  Lots of options, no changing the utility, everything driven 
by file data.

And the menu maintainer is also captive.

:-)

Examples:

IDX  LEN POS   TYPE  RMASK WMASK ----------NAME----------
   1    4   0 L-string   0     0  MENU KEY
   2    1   4 Byte       0     0  MENU SEQUENCE
   3    2   5 Integer    0     0  STATUS FLAG
   4   10   7 L-string   0     0  Function mnemonic
   5   30  17 L-string   0     0  Function-Menu name
   6   16  47 L-string   0     0  SPECIFIC-MENU DATA AREA
   7   16  63 L-string   0     0  SPECIFIC-MENU PROG AREA
   8   10  79 L-string   0     0  PROGRAM NAME-MENU KEY
   9    2  89 Integer    0     0  LINE NO. - MENU STATUS
  10    2  91 Date       0     0  START DATE
  11    2  93 Date       0     0  END DATE
  12    2  95 Integer    0     0  START TIME
  13    2  97 Integer    0     0  END TIME
  14    6  99 L-string   0     0  ABSOLUTE PASSWORD
  15    1 105 Byte       0     0  PASSWORD LEVEL
  16   30 106 L-string   0     0  SPECIAL DATA
  17    1 136 Byte       0     0  LINES TO SKIP
  18    6 137 L-string   0     0  CODES FILENAME

         !       Bit settings for record status flag
         !
         !               1       - <CR> prompt upon re-entry
         !               2       - codes look-up for special data
         !               4       - password required
         !               8       - keyer i.d. required
         !               16      - KB check required
         !               32      - USERNAME check required
         !               64      - use sequence from file
         !               128     - element is a menu
         !               256     - disable access of element
         !               512     - append data area to special data
         !               1024    - kill work file, program will detach
         !               8192    - action is a specific DCL command

And quite a bit more.

I guess I just believe in application specific stuff rather than one 
size fits all.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486