Hello again folks,
Thanks to the useful help of John Ferlan I was able to dig deeper into the problem ( original message below).
After discussing the code associated with C2 security further, We found that Tru64 has its own version of insque (see dbx output below). This meant that the source for CAP was using its version (called in abqueue.c and defined in abqueue.h) over Tru64's.
Anyway taking the *long* way round we got CAP working. But fortunately at the same time, got some great advice from John that assisted us in updating the C2 components of CAP to use proper sia calls, I will include the emails John sent me.
Many thanks also to Paul Crittenden who offered his distribution of CAP, John just beat you to it :)
Also, I have informed the maintainer of CAP, David Hornsby, about the issue and am supplying him with some diffs to include as a new patch (Cripes! that will make 202).
Once again Tru64 Managers to the rescue!!
Cheers,
Adrian.
David's Emails :
I haven't' looked at the code - but I figured I'd respond asap so that you know I at least received your e-mail (I canceled the return receipt)...
> > I would like though to understand why it's being called -
> > that is the context of the call. More directly to figure
> > out what FPlogin and OSlogin calls are doing. If for some reason
> > calling the getprpwnam with an incorrect parameter is causing
> > the core I need to know that too.
>
> The parts of the attached code you may want to look at are labeled with "DIGITAL_UNIX_SECURITY"
> as an ifdef. The part of the code that calls getprpwnam is:
> # ifdef DIGITAL_UNIX_SECURITY
> pr = getprpwnam(nam);
> if (pr == NULL || strcmp(bigcrypt(pwd, pr->ufld.fd_encrypt),
> pr->ufld.fd_encrypt) != 0)
>
This is as I expected. While this does work "most" of the time - the password in fd_encrypt isn't necessarily created by the result of a bigcrypt(). What's in there depends on the value of the fd_newcrypt field. Second, the way I read that code - it's got a problem especially when ufld.fd_encrypt
is NULL. One must check the ufld.fg_encrypt for being set. If that's set, then what's in fd_encrypt will be valid.
Of course, I don't recommend validating the user knows the password in this manner. Since all the code appears to be doing is validating the password, you could just call sia_validate_user() with the appropriate arguments. That way whether base or enhanced security is installed (or any other
mechanism), the proper validation will be done.
In 99% of the code I see this is the case - all the code wants to do is validate that the user knows their password.
> This is in afpos.c
> Basically it does a string compare from what the user entered to the crypted passwd in the prpasswd database. pls correct me if I am wrong. I am _not_ a C programmer by any stretch of the imagination :)
Yes - your reading is basically correct. it would be interesting to note what the results of an:
/usr/tcb/bin/edauth -g <username>
are for the account you attempting to authenticate to...
>
>
> an interesting note to consider is: if I enter a wrong username aufs does not core dump. However if I enter a correct username and any password (right or wrong) it core dumps. And like I said in my email to the list, aufs works fine in base security, obviously bypassing all ifdefs associated with
> DIGITAL_UNIX_SECURITY.
ah - so you have to rebuild when ES is installed. Again usage of the sia_validate_user() routine would bypass that for all instances. That is - wherever the non ES comparison is done (strcmp and crypt), you would replace that with a call to sia_validate_user() and it "should" work... I've
attached a sample piece of code that calls sia_validate_user() for you to look at (and test out).
> > Finally, if you can tell me when (what release)
> > this first occurred as compared to a previous one where it doesn't, that
> > would help.
>
> As far as I am aware this has not been an issue on any 4.0x box ( we have over a dozen machines running it at present).
Ugh - many changes have occurred since v4 days. I was hoping you'd say it worked in 5.0a, but failed in 5.1 - a much narrower difference!
I'll dive into the code and see what else I can find and let you know. Of course I don't have a MAC to do any testing, but you've narrowed my search down to a few modules with the ifdef...
--
John
-----------
Ok - let's break this down further...
The following program essentially does what OSlogin() in afpos.c does:
/* compile cc -g -o foo foo.c -lsecurity */
/* run ./foo username password */
#include <stdio.h>
#include <sys/secdefines.h>
#include <sys/security.h>
#include <prot.h>
#include <sia.h>
char *bigcrypt();
main (int argc, char **argv)
{
char *nam, *pwd;
struct pr_passwd *pr;
int auth_stat;
set_auth_parameters(argc, argv);
nam = argv[1];
pwd = argv[2];
pr = getprpwnam(nam);
if (pr == NULL || strcmp(bigcrypt(pwd, pr->ufld.fd_encrypt),
pr->ufld.fd_encrypt) != 0) {
printf("Incorrect password\n");
}
/* Same thing done a different way */
auth_stat = sia_validate_user(NULL,argc,argv,
NULL,nam,NULL,0,NULL,pwd);
if (auth_stat != SIASUCCESS ) {
printf("Incorrect password\n");
}
}
On my v5.1 system this works fine with a valid account... So perhaps there is something wrong with your configuration on the 5.1 system. Please snip and compile the above program and let me know if it has a problem with your account.
--
John
> -----Original Message-----
> From: Adrian Yarrow [mailto:a.yarrow_at_cqu.edu.au]
> Sent: Tuesday, 23 October 2001 4:49 PM
> To: 'tru64-unix-managers_at_ornl.gov'
> Subject: CAP, on Tru64 5.1
>
>
> Dear Managers,
>
> I know this has come up recently, but my question is a little
> different. Would anyone have a binary copy of CAP 6.0 with a
> minimum patch level of 198 that they might wish to share with me ?
>
> I have been beating my head against a brick wall for two days
> now, trying to get it working on Tru64 5.1 patch 3. The best
> I can manage, is a stable version _without_ C2.
>
> For those that are interested, or may be able to suggest a
> fix for this, here is the output of a dbx on the core file:
>
> dbx /usr/local/cap/bin/aufs ./core162185
> dbx version 5.1
> Type 'help' for help.
> Core file created by program "aufs"
>
> signal Segmentation fault at >*[insque, 0x1200539e0] ldq
> t0, 0(a1)
> (dbx) where
> > 0 insque(0x3ff800cff24, 0x60, 0x11fffbbf6, 0x10,
> 0x3ff80929a50) [0x1200539e0]
> 1 (unknown)() [0x3ff80929a74]
> 2 auth_cache_enter(0x0, 0x11fffbbf6, 0x200000001, 0x8,
> 0x3ffc02a8540) [0x3ff8092a62c]
> 3 (unknown)() [0x3ff8093a2ec]
> 4 auth_db_findent(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff8093a52c]
> 5 auth_lfile_findent(0x3ff80938750, 0x10, 0x11fffbbf6,
> 0x11fffb3d0, 0x3ffc02a90e8) [0x3ff80939734]
> 6 auth_lcl_findent(0x11fffbbf6, 0x11fffb3d0,
> 0x3ffc02a90e8, 0x10, 0x3ff8093817c) [0x3ff8093874c]
> 7 auth_svc_findent(0x1400014c0, 0x14001ebb0,
> 0x3ffc00a54e0, 0x11fffbbf6, 0x11fffbbf6) [0x3ff80938178]
> 8 afindent(0x11fffbbf6, 0x3ff00000000, 0x3ff80948910,
> 0x11fffbbf6, 0x11fffb8a0) [0x3ff8092ef34]
> 9 getespwnam(0x11fffb8a0, 0x11fffbbf6, 0x3ff80948988,
> 0x11fffbbf6, 0x140044b00) [0x3ff8094890c]
> 10 getprpwnam(0x140044b00, 0x1400015f0, 0x120019d20,
> 0x11fffbbf6, 0x11fffb8a0) [0x3ff80948984]
> 11 OSLogin(0x140020f70, 0x1400060f8, 0x11fffb9f0, 0x13,
> 0x2a) [0x120019d1c]
> 12 FPLogin(0x0, 0x0, 0x0, 0x0, 0x0) [0x120022d68]
> 13 SrvrDispatch(0x3ff800d3874, 0x11fffbe60, 0x1200120d0,
> 0xe000, 0x0) [0x120021bbc]
> 14 inferior_handler(0x3ff800d3824, 0x11fffbf50,
> 0x120011d80, 0x0, 0x8c001) [0x120012118]
> 15 main(0x140032200, 0x140032c00, 0x0, 0x0, 0x0) [0x120011dac]
>
> >From what is shown here, I am assuming something is wrong,
> internally with libsecurity.so ?
>
> Any help would be wonderful,
>
> Cheers,
>
> Adrian Yarrow
> UNIX Systems Manager
> Information Technology Div.
> Central Queensland University
>
> Email: a.yarrow_at_cqu.edu.au
> ph: +61 7 49309996
> fx: +61 7 49309254
>
Received on Thu Oct 25 2001 - 12:01:31 NZDT