[1,1] vs [SYSTEM] ie. [1,4]

[Art Wiens]

What is the significance of many "things" being owned by the (non-existant) [1,1] account? Lot's of audit talk around here and "inquiring minds" want to know why VMS installs this way.

Would best practice be to set ownership of everything [1,1] to [1,4]? Or actually create a [1,1] account?

And as a bonus question, why does a group identifier ([1,177777]) not get created for the [1,*] group?

Cheers,
Art

[Joseph Huber_1]

This issue was dicussed here some time ago, maybe have a look at:
https://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1230665

[Art Wiens]

"set ownership of everything [1,1] to [1,4]?"

Or vice versa? eg. the initial system root created is owned by [1,1], however when I added a second root to the disk with CLUSTER_CONFIG (logged in as user SYSTEM), it creates it with the owner of [1,4].

Which is "correct"?

I did read the quoted previous post ... I should just tell the auditors to accept it as a "historical fact"? We have a whole list of those already that they're not happy with ;-)

Cheers,
Art

[Jan van den Ende]

Art,

UAF> add/ident SYSTEMBUILD/VAL=UIC=[1,1]
would give the displays a "nice" human-friendly appearance.
-- and you can always "explain" that the original system was generated, hence "SYSTEMBUILD", and the next roots were "added" by "SYSTEM". QED :-)
Worked for our editors, but then again, they had VERY little VMS knowledge, and VMS had relatively little to explain compared with Unix and M$.
(explanations were asked after an external party had been brought in to look for and report "suboptimal security points")

hth

Proost.

Have one on me.

jpe

[Hoff · Accepted solution]

If you want to know and research the undocumented and arcane history of UICs on OpenVMS, this whole area has its share of weirdnesses, bugs that have become features, and legacy behaviors. Some go back into RSX-11. Some are simply inexplicable. Some appear to be old bugs that became set in concrete when they shipped.

[1,2] was LIB. [1,10] was Field. [1,54] was one of the SYSEXE directories. There are many others. This was way more common prior to V4; back when parts of VAX/VMS itself needed RSX compatibility mode.

Everything owned by [1,1] is a perfectly normal and correct and expected /SYSTEM volume.

1: Best practices? Ignore it. This is normal. (I'd not tend to stray off the rails here and tweak this to be "pretty", lest some future ECO or upgrade run into the tweaks and tip over.) (BTW, it is likely that you will not be able to reset ownerships of everything over to [1,4] due to file locking - init and mount a scratch volume and try it.)

2: because there's a collision with the username and the account name (for the first username created in the [1,*] group) when the system and its usernames are initially configured. Longstanding bug/feature/oddity.

This is a dark and dank and ancient and somewhat smelly corner of the whole environment, and (IMHO) best left alone and untouched.

[John Gillings]

Art,

"We have a whole list of those already that they're not happy with ;-)"

What are they not happy about? This is the standard, out-of-the-box OpenVMS configuration that has passed C2 and even (for SEVMS) B1 security. If they're not happy, what would they like them changed to? Are they comfortable with the potential risks?

As Steve has pointed out, the group identifier SYSTEM cannot be created automatically as there is already a username identifier SYSTEM. I've seen people create group identifier "SYS", but I don't know if it was a help or hinderance.

From an auditing perspective, there is no practical distinction between any UICs below MAXSYSGROUP, except to identifiy different users in audit logs (but then any of them has sufficient privilege to forge audit records...) Since there is no user [1,1] it can be thought of as indicating something owned by "the system", but not by the username "SYSTEM".

Jan's suggestion of creating an identifier may help the uninitiated comprehend it better, but it has no real impact on the security of the system. The risk is there may be (poorly written) software which assumes it will see ownership as the string "[1,1]" for system objects, which might be broken by such a change.

Remember, all this stuff dates back to V1.0 and beyond to prior operating systems. The broader security framework, including identifiers and ACLs was introduced in V4, WAY too late to change the historical baggage, so we're stuck with it.

[Hoff]

Less than or equal to MAXSYSGROUP.

Caution: UICs are shown in octal, MAXSYSGROUP is shown in decimal.

--

INITIALIZE

/SYSTEM

Requires a system UIC or SYSPRV (system privilege) privilege.

Defines a system volume. The owner UIC defaults to [1,1].
Protection defaults to complete access by all ownership
categories, except that only system processes can create top-
level directories.

--

As for OpenVMS and auditors, the "Standard Ownership and Protection" appendix here tends to help:

http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.HTMl

--

(Yes, that file name is cap-HTM-lowercase-L. Go figure.)

[Joseph Huber_1]

In my systems (several system disks) I can't see a single file or directory owned by [1,1].
The system disks started as version 1.5 factory installed in 1994, and never have been initialized since (except by image backup).
Maybe it had an initial SYS0.DIR owned by [1,1], but this has been removed since.

So I think nothing in VMS requires [1,1] ownership, and changing from [1,1] to [system] should not be dangerous (just to satisfy the "auditors").

[Richard W Hunt]

Running on an OpenVMS 7.3-2 (for Alpha) I was able to change everything I found with 1,1 ownership to 1,4 (SYSTEM) ownership. I had to... my auditors said either every file had a valid owner name OR they would shut me down. (I am a government contractor, by the way.)

So taking a laissez-faire attitude to [1,1] is not always possible. The good news is that OpenVMS 7.x allows you to make the required changes, even to the volume itself.

The only time this difference ever gave me fits was the weekend (many, many years ago) when our group transitioned from VMS 4.7 to 5.2 on a mixed-size VAXcluster. The upgrade just would not fly. Until we found that one of the commands was having trouble because the GROUP-level permissions for 1,1 didn't allow SYSTEM (at 1,4) to update or delete files. Even though MAXSYSGROUP was set correctly at the time. After a late-night call to Colorado and a bunch of detective work on our part, we found the booger that was set wrong and fixed it. We have been using SYSTEM as owners of every resource except the stuff that a couple of third-party packages require.

And thanks for the reminder of RSX-11M. What a little workhorse that O/S turned out to be!

[Robert Gezelter]

Richard,

I understand the auditor *issue*. That is why I would personally recommend that Art create an identifier (and a DISUSERed Username, if needed) without changing the file ownerships.

The Identifier is a far safe alternative.

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