restricting MONITOR for unprivileged users

[Jess Goodman]

Is there a way to use an INSTALL command (REMOVE or REPLACE) so that users without WORLD, CMKRNL, etc. privileges can not use MONITOR PROCESSES, etc. to get a list of all processes on a system?

For such users the SHOW USERS and SHOW SYSTEM command will only display the processes that they own - after you have done an INSTALL REPLACE SHOW command that removes WORLD privilege.

I'm looking for a similar way to restrict the information that MONITOR will display. I'd rather not have to change the file protection on MONITOR_TV.EXE itself.

Alpha VMS 7.3-2.

[Hoff]

What's some background on your goal(s) here? What requirements or security or mechanisms or limits are you seeking to resolve with this particular MONITOR approach?

The usernames are not generally considered sensitive per most typical military security reviews; this sort of data is really hard to completely lock down. You can probe users with MAIL, for instance.

Here, I'd just protect MONITOR, or remove it. Hacking the default protections and settings of OpenVMS will increase support costs. But if you're in for a penny, you're in for a pound.

For higher security, just don't let random folks at DCL. Using the CAPTIVE flag is typical here. Or don't let folks onto the box (interactive) at all.

[David Jones_21]

If I had to go the route of changing file protections, I think I'd rather protect sys$share:spishr.exe (which provides the getspi system service) than the monitor image.

[Jess Goodman]

We have clients who use our VMS systems interactively to run a large number of applications developed inhouse. A menu under a CAPTIVE account is not an option because the clients are encouraged to create their own .COMmand procedures to chain our applications together in whatever way they wish.

The clients have no access to MAIL, the network, or our compilers. (Yes, I know its possible to hack together an .EXE using an editor and DCL.)

We do not wish these clients to know the name, or even the number, of other clients on the system, or the name of our system processes.

We have removed WORLD and CMKRNL from VMS installed images, but that does not inhibit MONITOR.

We also have inhouse users who are trusted with WORLD privilege but not READALL/SYSPRV/BYPASS. So to protect MONITOR_TV or SPISHR from clients, but still allow any inhouse user to run MONITOR my only option seems to be using an access control list.

My question is: Are there any other options?

[Hoff]

>My question is: Are there any other options?

Do what various secure sites do? Pick bogus usernames. Done. If you're really paranoid, make them one-shot names.

If you want to offer timeshare in parallel, then some stuff is going to be visible. It's _really_ hard to hide this stuff, which is why even systems evaluated to NCSC Class B1 security don't try to hide this sort of user data.

If the box is capable of it (and you're willing to pay for the option), you could also brute-force it and use OpenVMS Galaxy. Or with a small fleet of boxes, roll in a prebuilt OpenVMS installation, and treat the box as a single user. Or there's always emulation, too.

Or you tell the customers that "some aspects of your on-line activities might be visible".

[John Gillings]

Jess,

Although MONITOR is a privileged image, it's not those privileges that enable it to gather information about other processes. It uses SPISHR to get performance information. SPISHR is a protected image, and uses that mechanism to access otherwise privileged information.

I doubt SPISHR would work if not installed protected. If there are legitimate things your uses should be able to do with MONITOR, you may be able to implement your own version with your required limitations imposed. That won't block users acquiring a distribution copy of MONITOR, and/or writing their own code which calls SPISHR.

Another option would be to implement you own SPISHR which obfuscates process and user names, maybe just replace them all with PID strings?

Note that it's one thing to break the ability of MONITOR to display real time information. It may be entirely different to block it from recording a snapshot and playing it back (possibly on a different sysetm).

[Art Wiens]

I'ld argue that if it were possible to do what you want, it would end up creating more grief. Users who felt the system was "slow" would invoke monitor, not see the foreign process consuming 101% cpu ... and would call straight away saying "there's something wrong with the system". The support staff would have the life sucked out of them reciting "there are some processes you can't see ..."

Different DCLTABLES with and without MONITOR? Or an ACL to allow MONITOR for "power users" only?

Cheers,
Art