Everything related to the OpenVMS security model, system access, system and data protection, and security auditing.
-
Topic author
mfaynberg
- Member
- Posts: 5
- Joined: Wed Oct 04, 2023 6:17 pm
- Reputation: 0
-
Status:
Offline
Post
by mfaynberg » Thu Oct 26, 2023 5:03 pm
I installed OpenVMS 9.2-1 on the VM hosted by Rocky Linux. It works OK, however I am facing a strange problem. By default upon the installation I only had the System account. Now I created another account, let's call it User and assigned all rights to it - so that it would in this respect be identical to the System. Then I changed the System's UIC from [1,1] to [41,1] according to our system configuration requirements. What I am facing now looks strange: when I am logged as a User, and send command
$ dir dka0:[000000]000000.dir
I receive the proper response, However if I add any qualifier like /dat or /full the response is:
Code: Select all
HSQX86$ dir dka0:[000000]000000.dir/dat
Directory DKA0:[000000]
000000.DIR;1 insufficient privilege or object protection violation
Total of 1 file.
As a result I cannot even perform full disk search...
What could be wrong?
Thank you!
-
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Thu Oct 26, 2023 5:46 pm
Code: Select all
> What could be wrong?
I'd guess that someone made undesirable changes to the standard VMS
UIC and GROUP values, defeating the usual expectations.
> [...] Now I created another account, let's call it User and assigned
> all rights to it [...]
Not a very detailed description of this new account.
> [...] Then I changed the System's UIC from [1,1] to [41,1] [...]
Moving SYSTEM from (special) group 1 to (ordinary) group 41?
https://wiki.vmssoftware.com/UIC
[...] VSI reserves group 1 and groups 300-377 for its own use.
> [...] according to our system configuration requirements. [...]
Elaborate? Hint: Explain your actual requirements, not how you
believe the VMS configuration should be changed in order to satisfy
these (unspecified) requirements.
> [...] What I am facing now looks strange: [...]
So does what can be seen of your modified configuration. (File
ownership, for example, is invisible.)
"Doctor, it hurts when I do this."
"Don't do that."
-
Topic author
mfaynberg
- Member
- Posts: 5
- Joined: Wed Oct 04, 2023 6:17 pm
- Reputation: 0
-
Status:
Offline
Post
by mfaynberg » Thu Oct 26, 2023 6:11 pm
Ok, sms - thank you for your comments. You have a point and I was too superficial there describing the situation.
Here are the details:
1. User's account:
Code: Select all
UAF> sho hsq
Username: HSQ Owner: HSQ
Account: MISER UIC: [41,1] ([MISER,HSQ])
CLI: DCL Tables: DCLTABLES
Default: SYS$SYSDEVICE:[USERS.HSQ]
LGICMD: LOGIN
Flags:
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 8 Login Fails: 0
Pwdlifetime: (none) Pwdchange: (pre-expired)
Last Login: 26-OCT-2023 09:38 (interactive), 26-OCT-2023 12:39 (non-interactive)
Maxjobs: 0 Fillm: 400 Bytlm: 46400
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 350 JTquota: 10240
Prclm: 16 DIOlm: 350 WSdef: 20480
Prio: 4 ASTlm: 350 WSquo: 81920
Queprio: 4 TQElm: 100 WSextent: 20480
CPU: (none) Enqlm: 6400 Pgflquo: 800000
Authorized Privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS
CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP
GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT
NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE
SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX
UPGRADE VOLPRO WORLD
Default Privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS
CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP
GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT
NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE
SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX
UPGRADE VOLPRO WORLD
2. I realize that it might be not a good idea to change the System's group, but when I said "requirements" I meant that the system we have been shipping for 30+ years was always configured that way: both the System and Hsq accounts had the UIC of [41,1]. Yes this is a new VMS version and it is possible it treats it different, but on our old systems this setup does not cause any like problems - however it seem violating the rules. I am now thinking whether it is possible to intentionally make a group privileged despite it has an id of in this case 41?
Anyway, if I missed anything I will be happy to provide more info.
Best regards,
Mike
-
sms
- Master
- Posts: 370
- Joined: Fri Aug 21, 2020 5:18 pm
- Reputation: 0
-
Status:
Offline
Post
by sms » Thu Oct 26, 2023 6:48 pm
Code: Select all
> 2. I realize that it might be not a good idea to change the System's
> group, [...]
An explanation of the reason might be interesting.
> [...] the system we have been shipping for 30+ years was always
> configured that way: [...]
That'd be suggestive, at least.
> [...] Yes this is a new VMS version and it is possible it treats it
> different, [...]
Very (perhaps too) generally, VMS is VMS, so I wouldn't bet on that.
> [...] however it seem violating the rules. [...]
Perhaps. Perhaps not. In my (limited) experience, it's certainly
unusual/startling.
One other potentially interesting item I stumbled into while
searching this new Inter-Web thing:
https://wiki.vmssoftware.com/UIC_Protection
System refers to users with the UIC group of 0 through the value
of MAXSYSGROUP (10 by default; bear in mind that numbers in a UIC
are octal). [...]
Around here, it's always the default:
ITS $ mcr sysgen show MAXSYSGROUP
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
MAXSYSGROUP 8 8 1 32768 UIC Group D
I've never touched it, so I know nothing, but if you haven't jacked
MAXSYSGROUP up to at least 33 (%o41), then I'd give that a shot.
How complete/reliable is the system-mutilation procedure that you're
following?
It might also be interesting to see the characteristics (including
ownership and protections) of the MFD ("[000000]000000.DIR") and/or
other top-level stuff on the system volume.
-
thilo.lauer
- VSI Expert
-
Newbie
- Posts: 3
- Joined: Mon Oct 11, 2021 5:30 am
- Reputation: 0
-
Status:
Offline
Post
by thilo.lauer » Fri Oct 27, 2023 1:03 pm
> As a result I cannot even perform full disk search...
What makes you think that being unable to retrieve details from the file header of 000000.DIR will block you from performing ie. a DIR [000000...]?
BTW, I was unable to reproduce the system behaviour you described with V9.2. I fear we've only seen the tip of the iceberg of this issue, and there's actually much more to it - and I must say, I also fear I really don't like to actually see that mess.
Last edited by
thilo.lauer on Fri Oct 27, 2023 1:03 pm, edited 1 time in total.