Rocket U2 | UniVerse & UniData

 View Only

 uopy and security

David Rubie's profile image
David Rubie posted 06-20-2022 00:05
Hey everyone, complete noob here who has been tasked with implementing some stuff with uopy.

We have been reviewing the security of our proposed setup and have a few questions around uopy, the Unix user and the UniVerse user that we can't find any definitive answers for, so I'm hoping somebody in the community can lead us to the right bit of documentation for these:

1. It seems that uopy has the capability to run SH commands (limited by the VOC?).  Is there a way to completely disable SH?  My limited understanding is that the VOC can be written to by the UniVerse user so can they re-enable access to SH by themselves?
2. The uopy library seems to require a Unix user to operate.  If we disable the shell in /etc/passwd (or point their shell entry to /bin/false or something), would that have the effect of also disabling SH access via UniVerse?
3. If we have to have a Unix user for our uopy to operate, can be make ownership of all their files read-only so they can't be modified?  

Basically we're trying to make sure that in the unlikely event somebody discovered the Unix credentials being used to get to a UniVerse host, that the damage they could do was limited i.e. completely disable any interactive shell access, disable SH from the uv interface and limit their UniVerse access to only those files in their VOC and make that impossible to change with the compromised credentials.

cheers for any help or guidance on this matter.
dave.
John Jenkins's profile image
John Jenkins posted 07-08-2022 18:23
David,

The basic controls are the same as at TCL:
  • User rights and access permissions for the credentials used at the O.S level
  • Remote Verbs - aka Security Subroutines - it is possible to limit use of any TCL command or catalogued program according to locally-defined rules.
  • File triggers - it is possible to block the ability to write to file using locally-defined rules in a before-write trigger. It is even possible to log the very attempt to write as an attempted security violation. 
Security Subroutines and triggers can do anything a BASIC developer can create.
I would look at a combination of triggers and security subroutines for the use-case outlined. Hopefully this helps.

Regards

John Jenkins
(ex-Rocketeer [freshly retired] )
John Jenkins's profile image
John Jenkins posted 07-08-2022 18:37
Dave,

Look at file triggers to control who can - and cannot - update, and Security Subroutines (aka Remote Verbs). Along with O.S access controls and permissions these are the tools of choice - it's just the same as at TCL.

Regards 

JJ