SYSUAF Logicals /SUPER and /EXECUTIVE nice effect!

[Lachnitt_1]

Hi guys,

here nice story.

I have a VMS-box (7.3-2) with a second sysuaf for tests on another directory - we call it SEC_DIR.

I defined it like DEF/SYS/EXEC SYSUAF SEC_DIR:SYSUAF.DAT.

After tests I redfined DEF/SYS SYSUAF SYS$SYSTEM:SYSUAF.DAT.
(Some guys should recognize that i forgot the /EXE parameter, but later more on that.)

After that i want to relogin with the SYSTEM-password from the SYS$SYSTEM:SYSUAF.
It doesn't worked!
Hmm, maybe I set it again:
$ MC AUTHORIZE MOD SYSTEM/PASSW=ABC
Try to Login - doesn't works.
Check Logical SYSUAF:
$ SH LOG SYSUAF /FULL
"SYSUAF" [super] = "SYS$SYSTEM:SYSUAF.DAT" (LNM$SYSTEM_TABLE)
Checked Modification date of sysuaf.dat => is the actual date/time!

Ok I come to the end:

It seems that AUTHORIZE uses the shown Logical-Interpretation (here SUPER).
But the Login-Process uses the /EXECUTIVE.
The SHOW LOGICAL shows if a SUPER-Logical exists, only that, regardless if an additional EXECUTIVE Logical exists!

So a nice way to cheat yourself!!!

But the Question is, is this a bug or a feature?

Bye Kuddel!

[Wim Van den Wyngaert]

Authorize uses the sysuaf file, login uses a cache of it via security_server ?
Just a wild guess. Try restarting security_server.

Wim@home

[Richard W Hunt]

Feature.

You have to ask yourself when each logical is used. If you are logging in, normally at that point there IS no process under which you can run DCL (to have /SUPER mode), much less anything to run images where /USER mode makes sense.

The way this works, to the best of my knowledge, is that whatever intercepted your attempt to log in uses the "trusted" (/EXEC) version of a logical because originally, when the hardware TT driver intercepted the login attempt, it was running similar to an ACP, which runs in /EXEC mode. The networking drivers were ALSO running as ACPs therefore also /EXEC mode.

Remember the old VMS (pre-OpenVMS) principle that a USER-mode exit strips away things marked /USER and a DCL (SUPER-mode) exit strips away things marked /SUPER. An ACP was doing a CREPRC to create an eventual venue for DCL, implying that DCL wasn't there yet. So /SUPER and /USER things don't exist at the time of this CREPRC. Therefore, LOGINOUT has to limit itself to /EXEC logicals because it knows there should not be any /SUPER or /USER logicals that could possibly apply to it.

Now, on the other hand, AUTHORIZE is just a program that you can run from DCL. If it chooses to limit itself to /SUPER logicals, that's fine. Probably a good idea since at the time that you run it from DCL, you are not in USER-mode, so no /USER logicals should exist. But at least for AUTHORIZE, there is a reasonable expectation that it will have a context in which /SUPER logicals CAN exist. Which there was not for the case of LOGINOUT.

Hope that explains why each one does what it does.

[Uwe Zessin]

For some reason, AUTHORIZE used the maximized access mode of SYSUAF (it even works with a USER-mode logical), LOGINOUT obviously tells RMS to use protected (=EXECUTIVE) mode. It allows you to work on a copy of SYSUAF.DAT, but:

At least this is an inconsistency, because RIGHTSLIST.DAT is always being accessed trough EXECUTIVE mode and any change applies to the current system!

[Jan van den Ende]

The login process (running LOGINOUT.EXE) is running in elevated mode.
Outer mode (like Superviser) logical name tables are simply NOT seen in inner modes!
And it really should stay that way, if you do not want to severely impair VMS stability and security!

Whether AUTORIZE should also limit itself to EXEC mode may be another point.
Looks like a typical issue for John Gillings to really give another one of his phantastic lectures!

John?

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

It is a feature. It allows anyone to play around with a copy (needs read acess), or alternative version of sysuaf for reporting and script testing purposes. No privs needed.
Obviously you need full privs for the real thing.

Admittedly the 'hidden' logical name when present twice in the same table is odd, but as requested. You do get to see it on a wildcard lookup, and when you ask for the proper access mode

$ show log sysuaf/full
"SYSUAF" [super] = "SYS$LOGIN:SYSUAF.DAT" (LNM$PROCESS_TABLE)
"SYSUAF" [super] = "TEST.TEST" (LNM$SYSTEM_TABLE)

$ show log sysuaf*/full

(LNM$PROCESS_TABLE) [kernel]
[no protection information]

"SYSUAF" [super] = "SYS$LOGIN:SYSUAF.DAT"

(LNM$JOB_80DDBC00) [kernel] [shareable] [Quota=(3536,4096)]
[Protection=(RWCD,RWCD,,)] [Owner=[SYSTEM]]

(LNM$GROUP_000001) [kernel] [shareable,group]
[Protection=(RWCD,R,R,)] [Owner=[1,*]]

(LNM$SYSTEM_TABLE) [kernel] [shareable,system]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

"SYSUAF" [super] = "TEST.TEST"
"SYSUAF" [exec] = "SYS$SYSTEM:SYSUAF.DAT"

(DECW$LOGICAL_NAMES) [exec] [shareable]
[Protection=(RWCD,RWCD,R,R)] [Owner=[SYSTEM]]

$ show log sysuaf/full/acce=exec
"SYSUAF" [exec] = "SYS$SYSTEM:SYSUAF.DAT" (LNM$SYSTEM_TABLE)


It is not a bug because VMS can not read your mind. The system WILL follow that first logical in 'normal' cases (directory, convert,...). It will only follow the EXEC mode logical when specifically requested, such as LOGINOUT does. How is the system to know which access type you meant unless you tell it just so?!

Still, I have to admit that this has caught me be surprise at times also :-).

Cheers,
Hein.

[Ian Miller.]

Its a feature. However you may want to look at
DEFINE/NAME=NO_ALIAS
From the help text

"NO_ALIAS A logical name cannot be duplicated in the specified table in a less privileged access mode; any previously created identical names in an outer (less privileged) access mode within the specified table are deleted."

[Robert Gezelter]

Lachnitt,

As Hein pointed out, there is no magic here. The explanation is simple.

- LOGINOUT.EXE is a privileged shareable image. I do not have the source at my fingertips, it implicitly or explicitly forces the use of the EXECUTIVE_MODE translation.

- as noted, AUTHORIZE is just an ordinary program operating on a file identified by the SYSUAF and RIGHTSLIST logical names. These files may be the active copies, archive copies, or copies of files from another system (I have done all three). No privileges are needed, other than the access rights to the files.

The OpenVMS logical name facility is very useful. I published a whitepaper in Volume 3 of the OpenVMS Technical Journal (reprint available at either the OpenVMS www site or on my site at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html).

I also presented the use of these techniques in a hands-on workshop at HPWORLD 2004 in Chicago (an abbreviated set of the notes for the workshop can be found at http://www.rlgsc.com/hpworld/2004/N227.html).

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

Robert,


- as noted, AUTHORIZE is just an ordinary program operating on a file identified by the SYSUAF and RIGHTSLIST logical names


If DecNet is active, add the relevant network files NETPROXY (DN v4) or NET$PROXY (DN v5)

It should be noted, however, that the behavior of SYSUAF and RIGHTSLIST differs!
For RIGHTLIST only the /EXEC logical is honored, also by AUTHORIZE.

a never found a decent explanation for the difference.

Proost.

Have one in me.

Jan

[Uwe Zessin]

NET$PROXY is not for DECnet Ph V (login to a Ph IV system and do a DUMP/RECORD) - it is for use by SECURITY_SERVER and NETPROXY is kept for old-style programms that access this file directly.

[John Gillings · Accepted solution]

Sorry guys, it's much dumber than that!

It's not really a bug or a feature, just an historical artifact.

For login, SYSUAF requires a "trusted" logical name. That means DEFINEd /SYSTEM/EXEC. This is a security feature to prevent hijacking of the UAF without high level privileges. Note that it's not automatic just because LOGINOUT is INSTALLed, this is deliberately coded.

However, to AUTHORIZE, the UAF is "just a file", so it will follow ANY logical name "SYSUAF" in any mode and in any table visible to the executing process. First one found is the one used. The default is SYS$DISK:[]SYSUAF.DAT, so on a system without a system wide logical name, a fairly common gotcha is for the system manager to edit a "private" SYSUAF in the SYS$MANAGER directory and wonder why the changes don't take. This is really an artifact of the V1.0 implementation of SYSUAF and AUTHORIZE (maybe another legacy of Mr Cutler?)

Any non-privileged user can create their own SYSUAF with AUTHORIZE. Fortunately they can't make the system use it! Beware of the message:

%UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
-RMS-E-FNF, file not found
Do you want to create a new file?

This means you're not editing the "real" SYSUAF. If you say "YES" a file will be created, so NEXT TIME your fire up AUTHORIZE, you'll open that file without any warning.

RIGHTSLIST is different. It was implemented much later - in V4.0. It uses a more disciplined and structured model. Instead of J.Random program accessing the file directly, all accesses are done through system services. The file is always located via a trusted logical name. This means there a guaranteed consistent view across the system. Unfortunately, the consistency of RIGHTSLIST and the inconsistency of SYSUAF is itself an inconsistency! I think the proxy files are similar. Phase IV is like SYSUAF, Phase V is like RIGHTSLIST.

It could be argued that AUTHORIZE should probably be reimplemented using the $SETUAI and $GETUAI system services to eliminate this anomoly, BUT so many people are used to being able to "stage" a UAF using a private SYSUAF logical name. There are also much more important areas which need attention and (very!) finite engineering resources.

Bottom line - make sure the SYSUAF logical name is correctly defined on ALL systems, even if it's in the default location (Ian's suggestion of /NAME=NO_ALIAS is also a good idea).

[John Gillings]

Oh, almost forgot:

One other related gotcha with DEFINE/SYSTEM/EXEC... If you have SYSPRV privilege but NOT SYSNAM privilege, DEFINE/SYSTEM/EXEC will SUCCEED, BUT the logical name will be defined in SUPER mode, not EXEC. No warning, no error.

So, you can run into this issue even though you issued the correct command!

[Jan van den Ende]

One other related gotcha with DEFINE/SYSTEM/EXEC... If you have SYSPRV privilege but NOT SYSNAM privilege, DEFINE/SYSTEM/EXEC will SUCCEED, BUT the logical name will be defined in SUPER mode, not EXEC. No warning, no error.


yeah... how often have we all been hit by THAT?

And I really think it is an outright BUG, no excuses!

Proost.

Have one on me.

Jan

[Uwe Zessin]

"" This is really an artifact of the V1.0 implementation of SYSUAF and AUTHORIZE (maybe another legacy of Mr Cutler?) ""

You can blame him for many things, but I thought that V1 had a simple sequential file for user authorization.