[Open-scap] Need help understanding RHEL STIG findings

[Jan Ruzicka]

The reg exp "^[^r][^o][^o][^t].*:0" is same useless as ":0" because it doesn't differentiate between GID and UID.

Also for example: if entries in passwd were: 
badguy:x:0:0:BadGuy:/root:/bin/bash
toor:x:0:0:BadGuy:/root:/bin/bash

Expression would not catch the toor.

I suggest 
       grep ':0:[0-9]*:' test-pass  | grep -v '^root:'

Sincerely 
Jan Ruzicka

On Jan 30, 2013, at 21:36, Shawn Wells wrote:

> On 1/30/13 4:57 PM, Snyder, Chris wrote:
>> In V1R2 def:70 does point at tst:7000, but the test doesn't point to obj:7701, it points to obj:7001.
>> 
>> As I said before, I'm just getting started with all of this, but if I'm reading this right, it sure looks like it's finding all non-0 UID users and then comparing that list to 'root' (control state).  If that's the case then the operation in ste:7001 should probably be "equal" rather than "not equal".
>> 
>> Anybody disagree with this assessment?  Should I file a bug on this?
>> 
>>  <unix-def:password_test id="oval:mil.disa.fso.rhel:tst:7000" version="1" check="all" check_existence="any_exist" comment="all UID 0s are root">
>>       <unix-def:object object_ref="oval:mil.disa.fso.rhel:obj:7001" />
>>       <unix-def:state state_ref="oval:mil.disa.fso.rhel:ste:7000" />
>>  </unix-def:password_test>
>> 
>>     <unix-def:password_state id="oval:mil.disa.fso.rhel:ste:7000" version="1" comment="root">
>>       <unix-def:username>root</unix-def:username>
>>     </unix-def:password_state>
>> 
>>     <unix-def:password_object id="oval:mil.disa.fso.rhel:obj:7001" version="1" comment="uid 0 and not root">
>>       <set>
>>         <object_reference>oval:mil.disa.fso.rhel:obj:7000</object_reference>
>>         <filter>oval:mil.disa.fso.rhel:ste:7001</filter>
>>       </set>
>>     </unix-def:password_object>
>> 
>>     <unix-def:password_object id="oval:mil.disa.fso.rhel:obj:7000" version="1" comment="all users">
>>       <unix-def:username operation="pattern match" datatype="string">.*</unix-def:username>
>>     </unix-def:password_object>
>> 
>>     <unix-def:password_state id="oval:mil.disa.fso.rhel:ste:7001" version="1" comment="uid not 0">
>>       <unix-def:user_id operation="not equal">0</unix-def:user_id>
>>     </unix-def:password_state>
> 
> It's funny that the scan shows all other UIDs are non-zero, however 
> still creates a fail:
> https://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/10/stigscanresults-beforeaqueduct.html#ruleresult-idp28475168
> 
> I believe I filed a bug with DISA on this content some time ago (Oct 
> 2012?) but can't find any emails on the matter. Here's how the RHEL6 
> content addresses it:
> http://people.redhat.com/swells/scap-security-guide/RHEL6/input/checks/accounts_no_uid_except_zero.xml
> 
> (Note: a browser likely will not render that correctly, view in an editor)
> 
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.