Block All Users From Getting To The Dollar ($) Prompt

[Edwin R. van der Kaaij]

Hello All,

We have 1000's of users and a handfull of application managers, privs range from NONE,GROUP,DEVOUR,SYSTEM,FILES and ALL.
We have a mix of DisCtlY DefCLI Captive flags set.
We want to keep everybody from the $ prompt. At the present different users can spawn to the dollar from MAIL>.
I'm asking for input from everybody how to keep people from the $ prompt.
Thanks in advance for your input!
Edwin R. van der Kaaij

[Jan van den Ende]

Yeah Ed,

I recognise that!

And you probably also have some applic's that _DO_ spawn subprocesses, so you can _NOT_ block spawn, right?


The way _WE_ have recuced the impact is having ALL users login to a menu structure.

Whoever is authorized for the danger applics, like eg MAIL, can only activate it as an entry FROM that menu.

And before starting each of those applics ALL enhanced priv's (and applic access identifiers!) are removed, (and restored upon exit). Now a spawned subprocess has NO enhanced priv's.
Of course, the protections on the entire system should be such that without privs or identifiers a user can only access his own SYS$LOGIN.

Hope this helps.

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

You possibly need the RESTRICTED flag on those accounts that are not allowed CLI access.

You may also want to check out /PRCLM=0 to prevent spawning a sub process.

This is all described in gory detail in the OpenVMS Guide to Security, chapter 7, notably the table in 7.2.1 "Types of System Accounts", and 7.2.4 "Captive accounts"

If need be, then please refine your question in the context of what is already documented there.

Personnaly I prefer to rely on controlling access, protection instead. But I appreciate that some environment want to hide VMS further.

Met vriendelijke groetjes,
Hein.

[Robert Gezelter · Accepted solution]

Edwin,

I cannot overemphasize the necessary use of CAPTIVE, etc (see an abstract of my presentation from HPWORLD 2004 at http://www.rlgsc.com/hpworld/2004/N227.html).

In any event, I want to particularly comment on the use of menus. Since CAPTIVE users cannot access a "$" prompt, menu's are necessary. HOwever, menus should not be relied upon as a security technique. Use ACLs, RIGHTS IDENTIFIERS, and other security tools to enforce security. In short, the menus may ommit options, but do not presume that they can be trusted.

As an aside, consider that the SYSUAF entries for such accounts SHOULD NOT execute anything out of the user's default directory. A classic problem, is that many programs require write access to the default directory. Thus, it can be possible for a user to overwrite his assigned LOGIN.COM.

Carefully thought out, OpenVMS can be used to implement a highly secure applications environment, that will withstand a serious audit.

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

[Lawrence Czlapinski]

Bob, We put the captive LOGIN procedures in a different directory [CAP_USER] with only W:RE. That protects against the captive users overwriting the LOGIN.COM and the apps can write to the users default directory.
Lawrence

[John Gillings]

Bob is correct.

The ONLY way to ensure users can't access the CLI is with the CAPTIVE flag. That will block SPAWN from interfaces like MAIL. It doesn't matter how good you are at writing DCL, without CAPTIVE there are ways to break out of your procedure.

You may also want to look at the DISIMAGE flag. Although this may make writing your command procedures and menus a bit more difficult, it plugs many potential loopholes.

Also have another look at those users with privileges. Do they really need them? The answer is usually NO. All procedures need to be EXECUTE ONLY to the user (deny READ access), and preferably owned by SYSTEM.


Apart from the system stuff, you also need to cultivate a culture of respect for the systems. Your users should be REPORTING any loopholes they find, not exploiting them.

Carrot and stick... the stick is using unauthorized access is a punishable offense (you choose the punishment), the carrot is anyone who (accidently!) finds a loophole and reports it is rewarded.

[Lawrence Czlapinski]

John, we use the RESTRICTED flag which appears to be equivalent to the CAPTIVE flag. Yes, either CAPTIVE or the RESTRICTED flag is required.
$ON CONTROL_Y THEN LOGOUT
Lawrence

[John Gillings]

Lawrence,
RESTRICTED is NOT the same as CAPTIVE.

RESTRICTED means you will complete your LOGIN procedure, but you are not blocked from accessing the command prompt.

[Edwin R. van der Kaaij]

Thanks for your insights and pointers to the right places.

I have checked the uaf records for some of the accounts that we know that they get to the $. They are not CAPTIVE. There must be a reason why they are not. It was decided before my time, so I'll investigate on that.

Also I'll read up on the matters referenced in this thread.

Thanks again, Ed.

[Karl Rohwedder]

< There must be a reason why they are not. It CAPTIVE accounts e.g. can not use the RUN or the INQUIRE command and may not specify any options at the USERNAME prompt.


mfg kalle