Conversation
|
Looking at the testing farm results something seems off. Please take a look. |
c0d1cbf to
8fcaef4
Compare
@Mab879 Updated. Had to include hash stripping mechanism in to shadow probe testing scripts for consistency |
Mab879
left a comment
Mab879
left a comment
There was a problem hiding this comment.
Please see my comments and review the Sonar findings as well.
| prefix_len = 0; | ||
|
|
||
| /* crypt(3) hash ($id$salt$hash), keep lock prefix + method id ($id$) */ | ||
| while (*p == '!') |
There was a problem hiding this comment.
Seems this code is expecting $ to be in the hash format. After reading man 5 crypt that assumption isn't always true. We might want change how this handled.
| { | ||
| SEXP_t *un; | ||
| struct result_info r; | ||
| char stripped[8]; |
There was a problem hiding this comment.
While not in Fedora or RHEL there could be longer hash format. This static size might cause us issues later.
820bef8 to
58aadd4
Compare
|
|
Seems like this isn't SCAP compliant, we need to figure something else out. |
2 participants
Description
This PR fixes the problem with raw shadow password hashes appearing in OVAL results with two complementary approaches:
shadow_probe.c: Newstrip_hash()function replaces raw password hashes withprefix+idvalues before they enter the OVAL data pipelineoval_sysEnt.c,oval_recordField.c: The mask attribute now suppresses values in bothoval_resultsandoval_system_characteristicsoutputsRationale
/etc/shadowin collected OVAL itemsauthor sets
mask="true"AND the output format isoval_resultsoval_system_characteristics) always writes the full hash regardless of maskTesting
ctest -R shadowruns all shadow probe tests including the newtest_probes_shadow_strippedtest/etc/shadowwith following entry typesSHA-512 hashlocked+hashlocked-no-hashdisablednever-setBSDi hash locked/unlockedSunMD5 with roundsDES locked/unlocked$6$forSHA-512,!!$6$forlocked+SHA-512)