Password Policy module

[Richard W Hunt]

First, having a freeware BLISS compiler helps not at all. I cannot "legally" install anything I haven't declared for my machine. I can't upgrade versions of anything without permission. DoD is kind of paranoid right now.

I literally need permission to patch the system when patches are available. (OK, I get THAT permission easily, but there IS a chain of command even for a security patch.) I got gigged for failing to note that we had a legal copy of "PKZIP for OpenVMS/Alpha" on one of our machines. So suggestions to install BLISS32 won't help. But maybe I'll look at the code.

Second, thanks for the MACRO code. I'll look at it, but won't be able to use it outright. I'm doing two other tests - a minimum password age and a specific type of sanity check that our security types said I should implement. NONE of the tests are worth a darn if I can't even make a local copy of the password and username.

I'm using the login flag UAI$M_PWDMIX to signal whether this rule applies. Only folks who have the ability to set their own passwords will need this facility. (We have some who are so bound up tightly in shells that they cannot set their own passwords.)

Of course, the problem is that if I can't see the username, I'll never be able to do the implied GETUAI call. So I guess I'm just wondering whether the parameters are DESCRIPTOR, ASCIC, ASCIZ, or something else. Because as it goes right now, I'm not seeing the input parameters.

[Richard W Hunt]

As to the FORTRAN version, I believe it was the Freeware 40 disk, so that link might have been correct. I looked at the file and later downloaded a new FORTRAN manual so I could check the implied syntax of CHAR *(*) as a passage mechanism. Haven't gotten around to that yet because of other excrement impacting the rotating atmospheric destratification appliance. (Egad, I've been working with the government too long when I start using THAT kind of language...)

I think my next test is to restore the version from SYS$EXAMPLES and complile and link it according to stated procedures (as noted in the file itself). Then try to run it. Odds are it won't work because the things I'm doing early in the module exactly track the contents of the SYS$EXAMPLES version - like doing TEXT_IO.PUT( "Password = " ); followed by TEXT_IO.PUT_LINE( PASSWORD );

I see "Password = " but then it crashes the task. Literally, i.e. stack and register dump. Ugly.

[Volker Halle]

Richard,

when you get a stack dump (improperly handled condition), then it's easy:

$ SET PROC/DUMP

run the failing image

$ ANAL/PROC imagename.DMP

Then you're in the debugger and you can look - statically - at all the variables and memory contents. Should be easy to figure out, WHY the image crashed.

DBG> EXA/INS @PC

Volker.

[John Gillings]

>So I guess I'm just wondering whether the
>parameters are DESCRIPTOR, ASCIC, ASCIZ,
>or something else

Richard, the username and plain text password are passed by descriptor. You can expect them to be CLASS S, DTYPE T with a word length field.

Since you can't DEBUG your routine in situ (privileged image), you should make sure it works in a test harness. Call your routine from a program which just passes 2 stings by descriptor, run under DEBUG and check you can see pointers to the descriptors in R16 and R17 once inside your routine. You should see something like the following. Look for the "010E" descriptor class and type, then check the text with examine/ASCII (note: radix is set to hex).

DBG> ex/hex/quad @r16,@r17
0000000000020050: 00020058010E0009
0000000000020040: 00020048010E0008

DBG> ex/ascii:9 00020058
0000000000020058: 'PLAINTEXT'
DBG> ex/ascii:8 00020048
0000000000020048: 'TESTUSER'

Given that your error is HPARITH, I suspect it's something other than a problem with the arguments. If it were the arguments, I'd be expecting an ACCVIO of some sort.

Dumb question... does TEXT_IO.PUT_LINE handle descriptors correctly? (I thought that Ada wouldn't compile if it wasn't correct, but I'm not certain).

Here's a very simple test harness. It would be better to have one that prompted for username and password in a loop so once you get over this initial problem, you can debug the policy part easily without changing any real passwords!

.title test_password_policy
.psect data,rd,wrt,noexe
user: .ASCID /TESTUSER/
pass: .ASCID /PLAINTEXT/
.psect code,rd,nowrt,exe
.entry start,^M<>
PUSHAB user
PUSHAB pass
CALLS #2,G^POLICY_PLAINTEXT
RET
.END start

[Richard W Hunt]

OK, did the SET PROC/DUMP, ran a password change, examined /INST @PC

It is telling me it died on MACRO instruction

LDQ R24, #X0098(FP)

which it reports as being part of program line 221. Program line 221 is

TEXT_IO.PUT_LINE( USERNAME ) ;

in the sequence at the start of the code...

begin

RESTS := STARLET.SS_NORMAL
TEXT_IO.PUT_LINE( "PASSWORD POLICY" ) ;
TEXT_IO.PUT_LINE ("Called with:" ) ;
TEXT_IO.PUT( "USERNAME = " ) ;
TEXT_IO.PUT_LINE( USERNAME ) ;
TEXT_IO.PUT( "PASSWORD = " ) ;
TEXT_IO.PUT_LINE( PASSWORD ) ;
...
The rest of the filter starts actually picking apart the username and passwordd, but the above is very close to the sample code in SYS$EXAMPLES.

When I do a SHOW SYMBOL/FULL USERNAME, it tells me (for this particular entry point),

data PASSWORD_POLICY.PASSWORD_PLAINTEXT.USERNAME
Address: .(.%FP+152)
array descriptor type, 1 dimension, bounds: [136308:136308]
cell type: atomic type, character-coded text, size: 1 byte.

If I look at PASSWORD, it has a different address (%FP+160), different bounds, but the same description including size 1 byte.

The password I entered for the situation that got dumped was 12 bytes long. I have not yet tried other cases but it is interesting that if I examine PASSWORD, it is hex 0C, which is correct if that is an ASCIC string.

[John Gillings]

(aside... for after you've got this working)
I just checked the SYS$EXAMPLES source and found this comment:

--
-- Please consult the "VMS System Generation Utility Manual" for further
-- information on using the SYSGEN utility. You might also want to add the
-- following line to SYS$SYSTEM:MODPARAMS.DAT:
--
-- LOAD_PWD_POLICY = 1 ! enable site-specific password filters
--

I strongly recommend you do NOT set LOAD_PWD_POLICY as a CURRENT SYSGEN parameter. If it's set and your startup fails to install the password policy module for any reason, you can't set passwords at all! I always recommend you leave LOAD_PWD_POLICY to 0 in MODPARAMS, and put the SYSGEN commands to set it in line with the code that installs the module, only to be executed if the INSTALL is successful.

(Similar advice for LGI_CALLOUTS, but if that module fails to load with the parameter set, your system is unbootable with no obvious cause!)

[Richard W Hunt]

John, I have a couple of tiny scripts that do the steps on the fly to set or clear the LOAD_PWD_POLICY flag, define or deassign the system logical name, and INSTALL ADD or INSTALL REMOVE the image in question.

I keep one session open on my test system, do the install, switch sessions, do the test, switch back, remove the code, and tear my hair out. I'm pretty careful about not leaving the system with that little booger active when I'm not around.

[John Gillings]

Richard,

Looks like we clashed with my prior posting about debugging, which you may have missed.

Don't debug/test it with the image installed, use a test harness. There's nothing magic about the routine, it's just an ordinary piece of code that accepts two strings, does some processing and returns a result. You can (and IMHO *should*) do debugging and testing isolated from the real system.

Once you're convinced it's working, THEN install it and check it out for real.

This will be MUCH easier and safer to do all debugging and testing from a test harness.

[Richard W Hunt]

Built the shell (in BASIC), called the policy plaintext module from it with a valid username and a password that would have failed the complexity test. The username is one for whom the PWDMIX login flag is set. (That's my marker for eligibility.)

When I attempt to pick up the username I get a CONSTRAINT ERROR.

When I examine the registers for R16, R17, etc. I see

%R16: 000000001031B54A
%R17: 000000007AE38160
%R18: 000000001031B54A
%R19: 000000000000000C

I do not see the expected descriptor headers in the registers, because either the address part is zero or this is a descriptor type I've not seen before.

In the BASIC shell, my setup for the call to the ADA module looks like:

EXTERNAL SUB POLICY_PLAINTEXT(
LONG BY VALUE,
STRING BY DESC,
STRING BY DESC )

In ADA, my setup for the external linkage looks like:

pragma EXPORT_VALUED_PROCEDURE(
INTERNAL => POLICY_PLAINTEXT,
EXTERNAL => POLICY_PLAINTEXT,
PARAMETER_TYPES -> (
CONDITION_HANDLING.COND_VALUE_TYPE,
STRING,STRING),
MECHANISM => (VALUE, DESCRIPTOR(S),DESCRIPTOR(S) ) ) ;

When I examine the stack, I never see anything that looks like the type-S descriptor I would have expected to see.

I'm confused. I'm also about to try to write this puppy in BASIC just to break the logjam. NAHC. (Not A Happy Camper.)

Anyone have any ideas?

[Richard W Hunt]

Throwing in another tidbit:

Adding a line:

K := PASSWORD'LAST ;
or
K := PASSWORD'LENGTH ;

both now fail with %BAS-F-MEMMANVIO, which is followed by SYSTEM-F-ACCVIO point to reason mask 00 and VA = lotsa zeroes.

It points to the K := PASSWORD'LAST ;

When I trace back the stack it looks like the run-time library code has passed through SHARE$ADARTL (which is the module called out in the debugger break message),
SHARE$LIBOTS_CODE0,
something with a VERY long address but no name,
SHARE$LIBRTL_CODE0, SHARE$DEC$BASRTL,
another lengthy address with no name,
and finally at frame 6, my POLICY_PLAINTEXT routine.

The total number of invocation blocks is 22, including several null frames.

So my interpretation is that the two modules (shell and policy module) are trying to ask each other about something but miscommunicating. I don't understand quite HOW they are doing so, but they are.

If I do SHOW SYMBOL/FULL on USERNAME in the plaintext module, it now says it is a dynamic string descriptor type, which I might have expected. When I attempt to examine the contents of USERNAME in the context of the module, it says 'invalid array descriptor'

Have I reached the level of calling HP for software support yet?