[Open-scap] Need help understanding RHEL STIG findings

[Jeffrey Blank]

I might suggest moving this conversation to the scap-security-guide
mailing list.

I suggest this because this is where SCAP content (including OVAL) is
being created for the RHEL 6 STIG.

If a similar issue exists (which could occur if similar guidance in
scap-security-guide exists), then this is a very good chance for you to
"fix it early" and never have to deal with it in the RHEL 6 STIG.



On 01/31/2013 01:12 PM, Jan Ruzicka wrote:
> 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.
> 
> 
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 

-- 
___________________________
Jeffrey Blank
410-854-8675
Technology and Systems Analysis / Network Components
NSA Information Assurance