topic Re: user priviledges in Operating System - OpenVMS

user priviledges

Eric_369 — Wed, 31 Aug 2005 15:33:53 GMT

I am using the install utility to create known file entries, for my "C" applications, with enhanced privledges (bypass).
These applications are run by users who have minimal dollar-sign ($) priviledges. The applications are given
world execute protection so the users can run them. One of the applications that is run by minimal priviledged users
has system call sys$sndjbcw which completes with a good status. This system call runs a command file, with logging, which
runs an application. In the log created by this system call I get the following error:

Error opening primary input file SYS$INPUT
Insufficient privilege or file protection violation

and the command file quits.

I modified the priviledges for this minimalized user to have READALL as a default priviledge. Now, the command file runs
the application just fine and I get the following error at the beginning of the log file:

%DCL-W-UNDFIL, file has not been opened by DCL - check logical name

Can you tell me where this error is coming from and how to get rid of it?

Re: user priviledges

Bojan Nemec — Wed, 31 Aug 2005 15:42:40 GMT

Eric,

"Error opening primary input file SYS$INPUT
Insufficient privilege or file protection violation"

Be shure that this user can read the command procedure you submit with the sys$sndjbcw system service. Change the file protection not the user privileges.

Bojan

Re: user priviledges

Bojan Nemec — Wed, 31 Aug 2005 15:57:45 GMT

Sorry,

I didnt ansawer to yours second question.

Try to put a $ SET VERIFY at the beginning of the command procedure and see which command generates the error.

And now I see that you are new to this forum so:

Welcome to the VMS forum!

Bojan

Re: user priviledges

Willem Grooters — Wed, 31 Aug 2005 16:13:14 GMT

Check file IO in the commandprocedurfe and be sure to have /ERROR= on each step. CLOSE of a file that is not opened by DCL may cause this problem as well: you can check the contents of logical to prevent the problem:

$ OPEN/ERROR=No_infile IN
$! do your stuff
$! at end of process:
$ goto endjob
$!
$ No_Infile:
$! Just ean example!
$ S = $STATUS
$ write sys$output "Error opening file"
$!
$endjob:
$ IF F$TRNLNM("IN") .NES. "" then close IN
$ EXIT 'S'

Re: user priviledges

Eric_369 — Wed, 31 Aug 2005 16:28:20 GMT

Bojan,
Thanks! I decreased the user priviledge and changed the command file protection and it worked great; however, the second error:

%DCL-W-UNDFIL, file has not been opened by DCL - check logical name,

appears before the "set verify" command in the command file, like so:

%DCL-W-UNDFIL, file has not been opened by DCL - check logical name
$SET VERIFY
....

Eric

Re: user priviledges

Eric_369 — Wed, 31 Aug 2005 17:25:57 GMT

Willem,
In the following command snippet you posted do I use the name of my command procedure in the field?

$ OPEN/ERROR=No_infile IN
$! do your stuff
$! at end of process:
$ goto endjob
$!
$ No_Infile:
$! Just ean example!
$ S = $STATUS
$ write sys$output "Error opening file"
$!
$endjob:
$ IF F$TRNLNM("IN") .NES. "" then close IN
$ EXIT 'S'

Re: user priviledges

Phillip Thayer — Wed, 31 Aug 2005 17:54:51 GMT

Sounds like maybe the process login.com or system sylogin.com may be trying to open or read a file that has not been opened yet. Look through those and see if there is any files that abe being used.

Phil

Re: user priviledges

Bojan Nemec — Thu, 01 Sep 2005 01:27:18 GMT

Eric,

Use the same technique with the sys$sylogin and the login procedure. Put set verify at the begining of this files. To avoid displaying on interactive terminals which can confuse normal users you can do a set verify only for batch jobs:

$ IF F$MODE().EQS."BATCH" THEN SET VERIFY

Bojan

Re: user priviledges

Antoniov. — Thu, 01 Sep 2005 04:07:14 GMT

Eric,
nice to meet you.

If you have V7.3 you can simply define
$ DEFINE/SYS SYLOGIN_VERIFY TRUE
After of this all login procedure have set verify enable. When you deass SYLOGIN_VERIFY, verify turn off. In this way you have no to modify command procedures.

Antonio Vigliotti

Re: user priviledges

Eric_369 — Thu, 01 Sep 2005 12:24:40 GMT

All,
Thank you for welcoming me to this site. It is a site I've desired for a very long time. Your help was much appreciated and your comments led me to the solution of my problem.

The problem was in my login.com file. There I had the following command:

Write sys$output: f$time()

I change it to:

Write sys$output f$time()

removing the colon after sys$output, and everything worked perfectly!

There was one thing I didn't understand. That login.com and sylogin.com were called when I run a batch job. Does this mean that when I run a batch job as a user that I am logging into the system again in "batch mode" to process the command file?

Re: user priviledges

Lawrence Czlapinski — Thu, 01 Sep 2005 12:51:40 GMT

Eric: Yes, when you run a batch job, you are logging in again in BATCH mode.
If you do work between clusters or non-clustered nodes, you logon in NETWORK mode.
Lawrence

Re: user priviledges

Uwe Zessin — Thu, 01 Sep 2005 13:05:02 GMT

BYPASS is a _very_ dangerous privilege.

I hope you have properly written your program so that it only enables BYPASS when it really needs it.

Imaging the following case:
- you programm sends some output to the terminal
- your 'unprivileged' user executes the following command
-- before (s)he runs you program
$ define sys$output sys$common:[sysexe]sysuaf.dat;0

Guess what will happen?

Re: user priviledges

Eric_369 — Thu, 01 Sep 2005 13:49:38 GMT

Uwe,
I will consider this concern and look into it. The major safety measure is that the 'unpriviledged' user is logged into a captive account and has no '$' access. At no point in time does any program change sys$output. I imagine that it could be done from by a higher level user across a processes! Is this a possibility?
Eric

Re: user priviledges

Uwe Zessin — Thu, 01 Sep 2005 14:08:43 GMT

Yes, a captive account reduces the risk.

It depends on the capability of these 'higher-level' users whether they can do any damage that way. Do they need access to those privileged programs, too? Can you block access from them?

Re: user priviledges

Eric_369 — Thu, 01 Sep 2005 16:10:40 GMT

Uwe,
A point that I'd forgotten about concerning the 'unpriviledged' user is that they don't have the priviledge of using the define command even if they could get to the dollar sign.

Second, there is only one user with priviledge enough to do what I suggested and that is the system administrator.

Eric

Re: user priviledges

John Gillings — Thu, 01 Sep 2005 20:23:01 GMT

Eric,

> they don't have the priviledge of
>using the define command even if
>they could get to the dollar sign.

Nevertheless! When designing a program which will be installed with any privilege, it is still prudent to always disable any unnecessary privileges as the first executable statement in the program, then enable privileges immediately before they are required and disable them immediately afterward they are used.

If you're running V7.3 or higher, you can use INSTALL/AUTHPRIVILEGE=(BYPASS) to give the image the ability to enable BYPASS, but not have it enabled upon image activation.

If at all possible, use this option instead of INSTALL/PRIVILEGE (but even then, being paranoid about this type of thing, I would STILL strongly recommend having a $SETPRV(NOALL,TMPMBX,NETMBX) as the first executable statement)

Furthermore, you should protect the image so it can only be executed by authorized users. WORLD EXECUTE is NOT good. Use an ACL to limit access to users holding a rights identifier.

Although what you say may be true right now, you don't know if someone is going to add new users with different access rights to the system in future, nor do you know what changes may be made to the program. There are just too many possible ways exploit a privileged image.

All that said, it sounds like your application would be better implemented using a Project Directory (see OpenVMS Guide to System Security, Section 8.8.1.2.2 http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/00/78-con.html#projectaccountssettingup ), or as a "protected subsystem" http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/01/112-con.html#projectaccountsasprotectedsubsystems

Either of these mechanisms should give you the ability to create a far more precise solution in a much more secure manner, and without the inherent limitations of protected images.

BYPASS and READALL are THERMONUCLEAR hammers. If you find yourself resorting to using them to solve relatively simple problems, you should see big red flags and LOUD alarm bells. Think "huge security hole waiting to be exploited". OpenVMS has a very rich variety of security control mechanisms, please use them to keep your system secure.

Re: user priviledges

Uwe Zessin — Fri, 02 Sep 2005 00:06:40 GMT

Eric,
I might have misunderstood you, but the DEFINE command itself does not need a privilege. You can create logical names in your process and job logical name tables without additional privileges.

Re: user priviledges

Antoniov. — Fri, 02 Sep 2005 01:25:47 GMT

Eric,
my working user has no priviledge and I daily work without any trouble. Just for system manteinance I have to use SYSTEM.

Antonio Vigliotti

Re: user priviledges

Willem Grooters — Fri, 02 Sep 2005 02:28:28 GMT

Eric,

The snipplet is just an example how I would do IO in a command procedure. is the file you open to process. At any point you can get the error you found when you access a file not opened when expected like on READ, WRITE or CLOSE.
That this would happen with SYS$OUTPUT is a strange thing anyway.

I have to agree on the security issue, with all. BYPASS should NOT be used unless all other facilities fail.
IMHO a user environment should be such that no other privileges than normally granted (TMPMBX and NETMBX) are required. You can do so by setting up the right directory structures, protect them and all subsequent files by UIC, ACL or both. Use rights identifiers that can dynamicly be granted to users to access files they normally do not have to, at the moment they need that access.
There are just a few issues that require extra privileges, and then use John Gilling's suggestion to enable them just when needed and disable them afterwards.

Willem

Re: user priviledges

Eric_369 — Fri, 02 Sep 2005 10:57:33 GMT

All,
Thank you for the help. It is refreshing to be corrected and shown the pitfalls of a particular course of action. In this case using (BYPASS) priviledges on an executable. Instead of writing 3 or 4 replies I'll try to do it in just one, responding to each post.

Uwe wrote:
>>
Eric,
I might have misunderstood you, but the DEFINE command itself does not need a privilege. You can create logical names in your process and job logical name tables without additional privileges.
<<

Uwe,
I tried using the define command at the prompt for the 'unpriviledged' user and the system wouldn't let me do it. In order to get to the prompt I had to make the 'unpriviledged' user non-captive.
Eric

Antonio wrote:
>>
Eric,
my working user has no priviledge and I daily work without any trouble. Just for system manteinance I have to use SYSTEM.

Antonio Vigliotti
<<

Antonio,
This is goal I have in mind! All users will be 'unpriviledged.' Our support staff will be the only 'priviledged' or SYSTEM users.
Eric

Willem wrote:
>>
Eric,

The snipplet is just an example how I would do IO in a command procedure. is the file you open to process. At any point you can get the error you found when you access a file not opened when expected like on READ, WRITE or CLOSE.
That this would happen with SYS$OUTPUT is a strange thing anyway.

I have to agree on the security issue, with all. BYPASS should NOT be used unless all other facilities fail.
IMHO a user environment should be such that no other privileges than normally granted (TMPMBX and NETMBX) are required. You can do so by setting up the right directory structures, protect them and all subsequent files by UIC, ACL or both. Use rights identifiers that can dynamicly be granted to users to access files they normally do not have to, at the moment they need that access.
There are just a few issues that require extra privileges, and then use John Gilling's suggestion to enable them just when needed and disable them afterwards.

Willem
<<

Willem,
Now I understand what you were getting at with IO in a command procedure.

The issue with sys$output was that instead of writing to (sys$output) in batch mode it was writing to (sys$output:) a device that doesn't exist. I guess putting a colon after sys$output made it unrecognizable as a device/file.
Concerning the (BYPASS) issue with my executables, you all have helped me see the error of my way!
Eric

John wrote:
>>
Eric,

> they don't have the priviledge of
>using the define command even if
>they could get to the dollar sign.

Nevertheless! When designing a program which will be installed with any privilege, it is still prudent to always disable any unnecessary privileges as the first executable statement in the program, then enable privileges immediately before they are required and disable them immediately afterward they are used.

If you're running V7.3 or higher, you can use INSTALL/AUTHPRIVILEGE=(BYPASS) to give the image the ability to enable BYPASS, but not have it enabled upon image activation.

If at all possible, use this option instead of INSTALL/PRIVILEGE (but even then, being paranoid about this type of thing, I would STILL strongly recommend having a $SETPRV(NOALL,TMPMBX,NETMBX) as the first executable statement)

Furthermore, you should protect the image so it can only be executed by authorized users. WORLD EXECUTE is NOT good. Use an ACL to limit access to users holding a rights identifier.

Although what you say may be true right now, you don't know if someone is going to add new users with different access rights to the system in future, nor do you know what changes may be made to the program. There are just too many possible ways exploit a privileged image.

All that said, it sounds like your application would be better implemented using a Project Directory (see OpenVMS Guide to System Security, Section 8.8.1.2.2 http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/00/78-con.html#projectaccountssettingup ), or as a "protected subsystem" http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/01/112-con.html#projectaccountsasprotectedsubsystems

Either of these mechanisms should give you the ability to create a far more precise solution in a much more secure manner, and without the inherent limitations of protected images.

BYPASS and READALL are THERMONUCLEAR hammers. If you find yourself resorting to using them to solve relatively simple problems, you should see big red flags and LOUD alarm bells. Think "huge security hole waiting to be exploited". OpenVMS has a very rich variety of security control mechanisms, please use them to keep your system secure.
<<

John,
Thank you for the advice and links to properly implementing security on my system.
Eric