Operating System - OpenVMS
1748054 Members
4979 Online
108758 Solutions
New Discussion юеВ

Re: Enable/Disable dynamic identifiers in C.

 
SOLVED
Go to solution
Oscar van Eijk
Occasional Advisor

Enable/Disable dynamic identifiers in C.

Hi All,

I need to write some C code that can handle identifiers with the Dynamic attribute.

It needs to lookup if an ident has been granted (but I suppose $FIND_HOLDER will do) and if so en/disable like $ SET RIGHTS_LIST would do.

Using $PERSONA is no option, since (a) the software should run on VAX and Alpha anb (b) IMPERSONATE privs is not (always) available.

Any suggestions?

Tnx,
Oscar
19 REPLIES 19
Wim Van den Wyngaert
Honored Contributor

Re: Enable/Disable dynamic identifiers in C.

Put the code in a shareable image and install it with privs. Then link your program with it.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: Enable/Disable dynamic identifiers in C.

Or install the whole program with privs.

Wim
Wim
Hoff
Honored Contributor

Re: Enable/Disable dynamic identifiers in C.

Rather than installing with privileges, I tend to prefer using "Subsystem Identifiers". These will work like installing with privileges, though avoid the broad security implications of having those privileges. Subsystem identifiers are more targeted, and more controllable. (Though unlike INSTALL and privileges, subsystem identifiers are granted via the ACL. Not via INSTALL.)

Put another way, privileges can potentially be more powerful than strictly necessary for various application requirement(s). The identifiers can provide a more targeted solution.

FWIW, the IMPERSONATE (and formerly known as DETACH) privilege is seriously powerful, too. It's an ALL-class privilege, and easily able to grant any privilege and any access that might be required. It's a BYPASS-grade privilege.

For process creation under another UIC (if that's where you're going), you can also use $sndjbc or such. With privileges.)

I tend to use a server for this sort of function, and to define the interface between the client processes and the privileged process(es).

And as for the system service programming interface for the identifier question, do look to the $GRANTID and $REVOKID services.
Oscar van Eijk
Occasional Advisor

Re: Enable/Disable dynamic identifiers in C.

Thanks for your answers, but I think I need te be a bit more clear about what I need.

The software is a development environment where users have several roles (like developer, integrator, admin...) for several products.

The filesystem (incl. CMS) is protected using ACL's, so depending on which role is being selected, the proper identifiers have to be enabled. We're using UAF's dynamic attributes when the idents are granted.

Can $GRANTID/$REVOKID do this? I understood that's only for the the rightslist database...
Jan van den Ende
Honored Contributor
Solution

Re: Enable/Disable dynamic identifiers in C.

Oscar,

om te beginnen: WELKOM bij het VMS forum!

The issue.

You _DID_ state that the identifiers ARE all created with /ATTRIB=DYNAMIC, right?

Now, if you(r system manager) also UAF> GRANTs them with tis attibute, THEN __NO__ extra privs are needed to SET RIGHTS EN/DISable them.

Minor gripe (of mine): upon login, such identifiers are always ENabled. Several times in the past years I have been advocating the possibility to have them initially disabled, but in vain sofar.

Mind, this _IS_ on the assumption that your users in several roles ARE to be trusted to behave according to their role-of-the-moment.

If you seek to enforce it, then you really should look serouously into the possibilities offered by Protected Subsystems.

But if your users also have to be able to assume "admin" roles (and I assume that also applies to the VMS environment), then you ARE down to good old trust...

(we HAVE implemented to delegate certain system management functionalities from captive menus, but that is a complete config in its own right).

Tell us more, and we probably can help you better.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Oscar van Eijk
Occasional Advisor

Re: Enable/Disable dynamic identifiers in C.

Hoi Jan,

Dank je :)

Identifiers are created with /atrrib=dyn indeed. I know they're default enabled, we handle that in the SYLOGIN.
It's not that the users can't be trusted, but the environment is pretty complex and it's just to prevent mistakes (the admin role also does the actual grant).

The issue is, the software that should enable an identifier, has to be written in C for other reasons, so what I'm looking for is a system service (or a SET RIGHTS /JOB :-S).

Op je gezondheid,
Oscar

John Gillings
Honored Contributor

Re: Enable/Disable dynamic identifiers in C.

Oscar,

I'd have expected this to be a $GRANTID, but I can't see a combination of arguments that does it. If you have access to a results disk (OpenVMS listings), check out the code for SETRIGHTS to see how they do it.



re: Wim

>Put the code in a shareable image and
>install it with privs. Then link your
>program with it.

Sigh... Wim, you need to write out 100 times:

"There is NO SUCH THING as a privileged shareable image"

Although it's possible to install a shareable image with the /PRIVILEGE option - at least in the sense that you won't get an error message, it doesn't do anything (unless the image is activated as an executable image).

If you want to create a shareable image which executes with elevated privileges, it needs to be a user written system service. This is a whole different ballgame from linking a bunch of routines into a shareable image.
A crucible of informative mistakes
Jon Pinkley
Honored Contributor

Re: Enable/Disable dynamic identifiers in C.

Yes, $GRANTID is what adds an identifier to the process rightslist. It is confusing, since the AUTHORIZE (UAF) program uses the grant command when what it is really using is $ADD_HOLDER, which modifies the RIGHTSLIST file.

Subsystem identifiers are good when a program does all access to the protected objects. However, that does not seem to satisfy Oscar's requirement of "changing role".

As has been mentioned by others, the dynamic attribute specifically allows a non-privileged user to add and remove the identifier from the process rights. Therefore anything using it for security related issues is (nearly) pointless. It is a bit like granting a user an authorized privilege that is not in their default privilege set; all that is needed to enable the privilege is set proc/priv=all and all authorized privileges (other than SETPRV) will be turned on in the current privilege mask.

If that is "good enough", then Oscar could implement the solution with a command procedure. However, Oscar specifically stated this had to be done with a C program, without stating the reason for the restriction.

If your are going to do this with a program, this is what I would do, although I would verify that it works with CMS before writing a program.

Instead of using the dynamic attribute, I would use the noaccess attribute, and then use the program to turn the noaccess attribute off to enable the role, and turn the noaccess attribute back on to disable the role.

Create an identifier for each "role" with the attributes (resource,noaccess). Grant this identifier to every user that is authorized for the role, with the same attributes (resource,noaccess). Protect the object with an ACL specifying the identifier so that the special access is only available via the role identifiers.

The noaccess attribute will disable the ability of the users to access the objects unless the noaccess attribute is removed with $GRANTID. This will require privilege, but I think you are going to need the image installed with privilege anyway, to be able to use the $GRANTID system service, which states it requires a minimum of CMKRNL.

So your enable_role program will need to do the following (with at least CMKRNL priv):

1. Get requested role from user (via command line option).

2. Copy users input to local storage, and then validate what is in the local buffer. If not valid input then quit.

3. Determine identifier associated with role, and convert this ASCII ID to binary with $ASCTOID.

4. Determine if process has the identifier enabled with $GETJPI item JPI$_RIGHTSLIST (with your buffer based on size returned by item JPI$_RIGHTS_SIZE). This returns an array of identifiers and their associated attributes. Scan the list for the binary value returned by $ASCTOID. If the identifier is not found, then the user is not authorized for the role; exit. If found, look at the attribute longword for the KGB$M_NOACCESS bit. If the noaccess attribute is present, then you must remove it by calling $GRANTID.

5. Audit the change if needed. Be especially careful when doing any file opens to restrict to use of trusted logical names.

I didn't write a program to do all this, but I am reasonably sure it will work, based on the following test: created an identifier, granted the identifier to a non-privileged user, logged into that non-prived username, attempted to access files that only allowed access based on the identifier (this failed). Then from a process with CMKRNL enabled, used

$ set rights/enable/attribute=(nonoaccess)/id= ident

And then verified that the non-prived process could access the directory. The program should have the same effect for the process running the program as the set rights/enable shown above does for another process.

Good luck,

Jon
it depends
Jan van den Ende
Honored Contributor

Re: Enable/Disable dynamic identifiers in C.

Oscar,
as other indicated, $GRANTID is up to the trick, and if I read your OP correctly, may just be all you need.

Re Jon:

>>>
Subsystem identifiers are good when a program does all access to the protected objects. However, that does not seem to satisfy Oscar's requirement of "changing role".
<<<

Here I have to disagree.
With the slight extra requirement that no two different roles can use the same image.
All that needs to be done is enable protected subsystems on the disk(s) holding the executablesm defining role-specific subsystem idenfifiers, and installing the images with the relevant role-specific identifiers. Now all that remains is to (dis)allow access to role-specific files (other than the images) with ACEs that specify the subsystem idents.
Should you need the same imagefor different roles, then you will need two different copies, and just treat them as unrelated.

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.