user priviledges

[Lawrence Czlapinski]

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

[Uwe Zessin]

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?

[Eric_369]

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

[Uwe Zessin]

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?

[Eric_369]

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

[John Gillings]

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.

[Uwe Zessin]

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.

[Antoniov.]

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

[Willem Grooters]

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

[Eric_369]

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