Restricting User to not have access to AUTHORIZE.EXE

[Petr X]

Hi,
I'm dealing with current issue.
User has following privileges set:

Authorized Privileges:
SYSPRV,READALL ....
and same for Default privileges.

I'm seeking for a way of how to restrict such user to be able to access AUTHORIZE.EXE image as this privileges are needed for starting up certain app, but user should not be able to access user management tool.

Is there a way of how to manage it, even with SYSPRV privilege ??

I tried it with setting up new IDENTIFIER and restricting this IDENTIFIER from accessing it, but no luck so far ....

cheers & thanks for any response.

[Jan van den Ende]

Petr,

you should go the other way around:
Create an identifier, and make allow that identifier all necessary access that is now aquired via SYSPRV.
This goes for all kunds of file access.
Then remove SYSPRV.

What exactly do you mean by "needed for starting up certain app" ?
Can the app be started once by the bootstrap?
If you can tell us exactly what function in starting the app requires SYSPRV, most likely we will be able to guide you along.

Proost.

Have one on me.

jpe

[abrsvc]

The proces has the privs to avoid any restrictions that you have put into place. I would suggest that you take a different approach and perhaps grant the privs to the application executables rather than to the account. Install the application images with the required privs needed to run. That will grant the privs for the duration of the application only.

Do you have control over the application do do the above?

Dan

[Petr X]

well, it's a bit complicated;

Let me explain: first the environment is set to start certain app (lot of sub-processes) and currently it's done via user different than SYSTEM, but with already mentioned rights. I'm not allowed to change anything within this user in order to obey contract rulez ....
Customer is now requesting to create same user, who is able to start the app, but not to have access to AUTHORIZE.EXE image, so:

- I can't modify anything for current user ie, privileges, identifiers etc ....
- I think it's not possible to manage this task due to that SYSPRV privilege
-I'm seeking for a way around, if any exists ...?

cheers

[Petr X]

Yo Dan,
no, unfortunately I'm not allowed to change anything for the user who starts the app. As I wrote before I do have environment set = user has rights mentioned before, I need copy of this user (new user), but even if this user has SYSPRV privilege, it should not be able to access authoirze.exe image.
And the very question is, if this is even possible

cheers

[Jan van den Ende]

Petr,

>>>
And the very question is, if this is even possible
<<<

Short (and absolute, unchangeable) answer:
NO

Designed to be so starting at VMS 1.0

Proost.

Have one on me.

jpe

[Petr X]

I thought so .....

thanks for your response.

cheers
Petr

[Petr X]

Question answered.

[Craig A]

Are we totally sure that SYSPRV holders cannot be restricted to use AUTHORIZE.EXE and, by definition, SYSUAF.DAT?

Off the top of my head:

1. Create UAF$DENY identifier
2. Add hidden ACE TO SYSUAF.DAT:
IDENT=UAF$DENY, ACCESS=NONE
3. Grant UAF$DENY to those users who you do not want to access SYSUAF.DAT

It would be prudent to add in additional security audits to track attempts to circumvent the above.

Unfortunately, I do not have acesss ATM to the system I last set this up for.

HTH

Craig.

[Hoff]

Privileges are a fundamental access control mechanism of VMS.

There are no privileges and no mechanisms that control the (ALL-class) privileges, and SYSPRV and READALL are ALL-class privileges.

The control mechanism is the privilege.

Reductio ad absurdum.

[John Gillings]

Petr,

Another point here.. AUTHORIZE.EXE is just another NON-PRIVILEGED program. There's nothing magic about it. All it does is provide a (rather clunky) interface to view or modify a system authorization file SYSUAF.DAT, and some ancilliary files associated with system authentication (RIGHTSLIST, NET*PROXY, etc). Note that any non-privileged user can run AUTHORIZE and use it to create and maintain a private SYSUAF (but, of course, it won't be recognised by the system).

Even if you somehow were able to block the holder of two ALL class privileges from running AUTHORIZE, they would still be able to modify SYSUAF using alternative programs, or even raw DCL. There's no way you can block access to SYSUAF, because, by definition, it's THE file which the system uses to identify users.

The implication of this question is that the user with high privileges is not entirely trusted. If that's the case, the privileges should be removed. Turn this issue on its head. Rather than try to block all potential undesired uses by which privilege could be exploited (an infinite set), work out a way to selectively ALLOW privilege for just those actions which the user is required to perform.

There are numerous mechanisms available, but without a clearer decsription of why they are necessary, it's not possible to recommend how you can achieve it.