Tracking changes to logical name SYS$SYLOGIN

[John Gerland]

I'd like to be able to determine when a logical name is changed, specifically SYS$SYLOGIN. Setting audit on the system table is not workable, due to the volatility of the table. Besides, such an entry won't tell me which logical name changed, only that the table has changed.

Moving the logical name is not useful. If I define it in the less-volatile cluster table, I could get alerts to its changes. However, if it gets defined as well in the SYSTEM table, that is the definition which will get used when it is referenced.

[Jan van den Ende]

John,

to begin with:

WELCOME to the VMS forum!

Your question:

SYS$SYSLOGIN should not be changeable at all - except by a knowledgeable system manager. It really is best protected by NOT giving out (or only VERY scarsely) the privileges needed to change it.

Then you can (preferably at bootstrap) redefine it to point to where it does, in the SYSTEM table, in EXECUTIVE mode, adding the /NOALIAS qualifier.
Now, it needs even more privilege to overrule, and the use of SYSNAM and CMEXEC can also be monitored.
If you go more desparate and/or paranoid, you can write a little program in your favorite COMPILED language, and do the define in kernal mode, again with the noalias attribute.

--- but be aware that you COULD "paint yurself in the corner" if you ever want to change it after that! :-)

hth

Proost.

Have one on me.

jpe

[Hoff]

No such selectively-targeted auditing mechanism exists at the level of an individual logical name; you're going to have to filter the auditing fire-hose. Or use an alternative solution.

If SYS$SYLOGIN is changing in an uncontrolled and unexpected fashion while your servers are underway, then you have serious local system management issues.

SEARCH the whole disk for references to the logical name.

Also remove any ALL-class privileges and any implicit system privilege UIC settings from all but a select few folks, and to ensure expectations are set appropriately among those few. Consider setting up parallel non-privileged logins for those folks, and enable audits on the privileged logins.

The protections against these sorts of unexpected and untrusted changes are the privileges; there's no second-level mechanism to control this access.

Regardless, if SYS$SYLOGIN is changing in an uncontrolled and unexpected fashion (and not something that can be spotted with a SEARCH), then these servers have serious security issues.

[John Gerland]

Thanks for your replies.

Fortunately, this is not an active issue I am facing. We do have privileges limiting most accounts, and other normal controls.

Rather, I am being somewhat paranoid (isn't it in the system administrator job description?), and also trying to keep auditors satisfied. They seem to want to be able to tell which administrator went rogue, not just that one did.

[Hoff]

Ah, auditors. That group of folks can be a mixed blessing. If you get a good auditor (eg: one that actually knows security and can trade off risks, and particularly that knows OpenVMS and its security model), then you'll do well to listen. If you get a bad auditor (eg: one that's reading off a cookbook, and particularly one that's not familiar with the OpenVMS security model), then you're faced with a choice of following the recommendations and destabilizing or disabling the OpenVMS box, or escalating the decision to management.

One recent security auditor actually suggested disabling the SYSTEM username. (That's a Very Bad Idea, BTW.)

There's some OpenVMS auditing information here:

http://labs.hoffmanlabs.com/node/43

Including links to tools to review the security of OpenVMS (the OpenVMS SRR) that are available from US NIST, and other sources.

[John Gillings]

John,

You're in luck that there's a specific privilege for defining a system logical name, SYSNAM, and that one would expect that it's relatively rare that logical names are defined or deassigned.

If you audit successful use of SYSNAM, you should get specific messages telling you who changed which logical name.

$ SET AUDIT/AUDIT/ENABLE=PRIVILEGE=SUCCESS:SYSNAM

$ DEFINE/SYSTEM/EXEC TEST By_JG


%%%%%%%%%%% OPCOM 11-FEB-2010 10:48:48.15 %%%%%%%%%%%
Message from user AUDIT$SERVER on TEST
Security alarm (SECURITY) on TEST, system id: 1234
Auditable event: Privilege used
Event information: SYSNAM used to create inner-mode logical name (DEFINE/EXEC, $CRELNM)
Event time: 11-FEB-2010 10:48:48.15
PID: 00007C6D
Process name: JG
Username: GILLINGS_J
Process owner: [GILLINGS_J]
Terminal name: VTA6:
Logical name: TEST
Privileges used: SYSNAM
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)

(this is actually an alarm, but if you enabled audits, there will be an equivalent message in the audit journal).

[Hoff]

There's a slight hole in that SYSNAM-auditing approach. Well, technically, there are at least two holes. Here's the more subtle variation...

$ set proc/priv=(noall,tmpmbx,netmbx)
$ sho proc/priv
...
Authorized privileges:

...all privileges...

Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox

Process rights:
...
$ def/sys hello hi
$ sho log hello
"HELLO" = "HI" (LNM$SYSTEM_TABLE)
$ deas hello
%SYSTEM-F-NOLOGNAM, no logical name match
$ deas hello/sys
$

That's right; SYSNAM isn't the only path to creating a /SYSTEM logical name.

And yes, the above behavior is entirely documented and supported and intentional.

[John Gillings]

Hoff,

Fair enough.

"Requires write (W) access or SYSNAM (system logical name) privilege to place a name in the system logical name table."

I assume your UIC is in a system group? That would give you write access to the system table, and therefore not require SYSNAM.

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

Maybe disable write access to the table?

Since any process creating a system logical name should have SYSNAM, what are the potential negative side effects?

You could also add a access failure audit to catch anyone attempting to hit the table (which hopefully wouldn't be a deluge).