comparing UAF$Q_PRIV and UAF$Q_DEF_PRIV

[Arch_Muthiah]

Hi,

Env: MACRO 32, OpenVMS 7.3 on Alpha DS10.

UAF$Q_PRIV -- references to user's AUTHPRIVileges.
UAF$Q_DEF_PRIV -- references to user's DEFPRIVileges.

I have a predefined-lookup table which has list of certain security related privileges.

Currently I check UAF$Q_PRIV list for each users against the priv in the lookup table, this way my prog will list who are all the users having specific security related AUTHPRIVs.

But as there are possibilities where a user can illegally having certain priv as their DEF PRIV, but not in AUTHPRIV list.

In this case I have to check each user's DEFPRIV also against my lookup table.

I tested my prog successfully by comparing user's priv agianst UAF$Q_PRIV and UAF$Q_DEF_PRIV, but separetly.

My question:
Is there any single symbol in $UAFDEF macro, which points to both AUTHPRIV and DEFPRIV lists of each users?. So instead of testing separetly against UAF$Q_PRIV and UAF$Q_DEF_PRIV, I can that symbol.

OR

Is there any way of using OR or XOR to combine these two lists together, so that I can avoid writing lengthiest MACRO 32 codes.

Thanks in advance
Archunan

[Hein van den Heuvel · Accepted solution]

[admittedly this is a little out of my expertise area, as I tend to ignore or blast through most security for my (performance oriented) work, so be sure to verify my comments even more so than you should verify any comment a stranger makes in a forum]

You could first OR the PRIV and DEFPRIV masks in your program and tehn test the bits. No big deal.

But please consider WHY there might be a difference between DEF and AUTH and I think you will determine that you have no business in checking anything but AUTH.

Please consider your statement: "But as there are possibilities where a user can illegally having certain priv as their DEF PRIV, but not in AUTHPRIV list."

How can that be illegal?
If it is illegal, then fix it!

Surely any 'mismatch' is there intentionally, and designed securely.
Perhaps the DEFPRIV allows an action in (SY)LOGIN.COM, while captive and that priv is revoked before letting the user loose.

KISS!

Regards,
Hein.

[Arch_Muthiah]

Hein,
Thanks for your response.
Today I try my ORing AUTH and DEFPRIV and I will you know.

< Please consider your statement: "But as
< there are possibilities where a user can < illegally having certain priv as their
< DEF PRIV, but not in AUTHPRIV list."

< How can that be illegal?
< If it is illegal, then fix it!

Yes, I accept your points, I found in the customer site where few users are with CMKRNL DEFPRIV, but not in AUTHPRIV list. I already asked their sysadmin for the necessary change, but they don't want to do it. So I left with no option than listing those users too.

Thanks again and expecting more clue on this.

Archunan

[Robert Gezelter]

Archunan,

I second Hein's comments, as I have done exactly what he described (e.g., created accounts with an elevated privilege purely for the use of the SYLOGIN.COM command procedure, which then disables it). This is a one-way trap door, which is extemely useful, albeit one requiring careful configuration and auditing of the system.

As a quick check, ORing the fields together should be ok, but you want to be careful. Situations such as those descibed above will show as security hazards, even though they are not really hazards.

- Bob Gezelter, http://www.rlgsc.com
Chapter Author, "OpenVMS Security", Handbook of Information Security (2005)

[Jan van den Ende]

Archunan,

I usually see security assesments as a multi-step activity.
In the first, you .OR. the default & auth privs, and eliminate the bulk of accounts as potential problem accounts.
As a NECESSARY second step, EACH account not eliminated by #1 has to be evaluated, and (hopefully) be shown to NEED the special case, but having other constraints to mitigate the risk (like in Bob's example, switching them OFF in SYLOGIN, but many other situations can be construed).
Another way to treat these situations is to look if they can be eliminated altogether by smart use of IDENTIFIERS, INSTALLed images, or PROTECTED SUBSYSTEMS.

But, the most important thing is, that the situation _IS_ scrutinized and if necessary adapted.
That is all too scarse in our business nowadays!

Proost.

Have one on me.

jpe

[Arch_Muthiah]

Hein/Bob/Jan,

Thanks for your time responding for my question.

Hein: I tried ORing those AUTH and DEF PRIVs, I did not get the correct result.

I have tried two ways..

1st way
..
..
MY_VAR: .BLKQ UAF$Q_PRIV!UAF$Q_DEF_PRIV
..
..
MOVAB MY_VAR(R6),R6
MOVAL MY_LOOKUPTABLE,R7

; I have used the following method also
; BISQ3 UAF$Q_PRIV,UAF$Q_DEF_PRIV,MY_VAR
; MOVAB MY_VAR(R6),R6
; MOVAL MY_LOOKUPTABLE,R7
..
..
then traversing thru the bit set to find selective priv. Looks like it cleared most of bits. But
MOVAB UAF$Q_PRIV(R6),R6
MOVAL MY_LOOKUPTABLE,R7
this works fine, even for UAF$Q_DEF_PRIV.

Jan/Bob: I can not ask the customer to change their setup. They somehow want to have this facility to trace all user's DEFPRIV also.

Is there any other MACRO DEFs are there in the system (like $PRTDEF...) which points to all of these PRIV in a single MACRO symbol?

Thanks
Archunan

[Hein van den Heuvel]

Hmmm,

Seeing the attempt above one seriously wonders why you programming in MACRO.

Is there no language on the box you are more familiar with? This stuff can easily be done in Cobol, Fortran, C, whatever.


Why are you looking at $UAFDEF?
You should be using $UAIDEF $GETAUI and

>>> MY_VAR: .BLKQ UAF$Q_PRIV!UAF$Q_DEF_PRIV

This statement will allocate 444 quadwords = 1 ackward.
This seem hardly what you want or need to do.

You needed something like (untested, and undesirable):

MY_VAR: .QUAD
:
MOVAL record_buffer,R6
:
BISQ3 UAF$Q_PRIV(R6),UAF$Q_DEF_PRIV(R6),MY_VAR
MOVAB MY_VAR, R6
:

Alternatively you could just move the ORred mask into a register and have the routine look in the register directly.

Or you could possibly 'cheat' and just do
BISQ2 UAF$Q_DEV_PRIV(R6),UAF$Q_PRIV(R6)
MOVAB UAF$Q_PRIV(R6),R6


But what you really need to do is to use GETUAI and an itemlist for that. Something along the lines of:

my_priv: .quad
my_def_priv: .quad
:
itemlist: ... UAI$_PRIV .. my_priv ... UAI$DEF_PRIV .. my_def_priv
:
SYS$GETUAI
BLBC R0, error
BISQ2 my_dev_priv,my_priv
MOVAQ my_priv, R6


>> Jan/Bob: I can not ask the customer to change their setup. They somehow want to have this facility to trace all user's DEFPRIV also.

Sure you can! You will probably be doing them a favor

>> Is there any other MACRO DEFs are there in the system (like $PRTDEF...) which points to all of these PRIV in a single MACRO symbol?

Sorry, does not compute.


Hope this helps,
Hein.

[Galen Tackett]

Many, perhaps most, privileges work if you grant them in DEFPRIV but not in AUTHPRIV (though I don't know why one might do this.) Also see the P.S. below.

SETPRV, on the other hand, only works if it's in AUTHPRIV. Its presence it DEFPRIV alone is ineffectual.

I haven't explored this sort of thing exhaustively; I wonder if there are other special cases?

Galen

P.S. For some privileges at least, if you grant them in DEFPRIV but not AUTHPRV, once a user logs in they will be able to use that privilege, though once they SET PROC/PRIV=NOxxx they can't turn it back on. Again, I'm not sure why you'd do this.

[Jan van den Ende]

Galen,

re-read Bob Gezelter above for one reason (and there are others along those lines).

About SETPRV: I did not know that! Tested it, and you are right (which you knew, of course).
Never to old to learn eh? :-)

Proost.

Have one on me.

jpe

[Galen Tackett]

Jan,

> re-read Bob Gezelter above for one reason

I just re-read Bob's response. I must have just skimmed it the first time as I missed what he said about temporary privileges. Thanks for pointing me back at it.

Galen