Hi Gabe,

Yes, I am more familiar with OVAL syntax now and I understand why it is not
working.

The problem in my OVAL test is in this part:

  <ind:textfilecontent54_object id="object_at_system_accounts_allow_list"
version="1">
    <ind:filepath>/etc/passwd</ind:filepath>
    <ind:pattern operation="pattern
match">^([^:]+):[^:]+:[\d]+:[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>
    <ind:instance operation="greater than or equal"
datatype="int">1</ind:instance>
    <filter action="include">state_at_system_accounts_etc_passwd</filter>
  </ind:textfilecontent54_object>

  <ind:textfilecontent54_state id="state_at_system_accounts_etc_passwd"
version="1">
    <ind:filepath>/etc/passwd</ind:filepath>
    <ind:pattern operation="pattern
match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>
    <ind:instance operation="greater than or equal"
datatype="int">1</ind:instance>
    <ind:subexpression operation="greater than or equal"
datatype="int">500</ind:subexpression>
  </ind:textfilecontent54_state>


'<ind:subexpression>' in block in'<ind:textfilecontent54_state>' is getting
the subexpression pattern from '<ind:textfilecontent54_object>' which
contains the username; so comparing a username to be an integer 'greater or
equal to 500' is not valid.


My question is much simpler now:

How can get all usernames from /etc/passwd that have UID greater or equal
to 500 without using password_object? I have been trying to do this for
many days now without any luck.

Thanks for your time

--
Rodolfo Martínez

On Tue, Jun 7, 2016 at 1:03 PM, Gabe Alford <[email protected]> wrote:

> Hello Rodolfo,
>
> I just did a quick glance as I currently don't have the cycles to look
> into this but the "state_at_system_accounts_at_allow_uid" exclude filter is
> where this is not working. It is not filtering UIDs greater than 1 or 500
> for that matter.
> Specifically this subexpression is what is failing:
>
> <ind:subexpression operation="greater than or equal"
> datatype="int">500</ind:subexpression>
>
> Gabe
>
> On Thu, Jun 2, 2016 at 8:52 PM, Rodolfo Martínez <[email protected]> wrote:
>
>> Hi mpreisler,
>>
>> Thanks for you suggestion in IRC.
>>
>> This what I have so far, but it is still not working. I feel I am close,
>> but it is not working yet. I would appreciate any suggestion
>>
>> <def-group>
>>   <definition class="compliance" id="at_system_accounts" version="1">
>>     <metadata>
>>       <title>No system accounts in /etc/at.allow</title>
>>       <affected family="unix">
>>         <platform>CentOS 5</platform>
>>         <platform>Red Hat Enterprise Linux 5</platform>
>>       </affected>
>>       <description>Group owner for /etc/at.allow and /etc/at.deny must
>> exist.</description>
>>     </metadata>
>>     <criteria>
>>       <criterion test_ref="test_at_system_accounts_at_allow" />
>>     </criteria>
>>   </definition>
>>
>>   <!-- This variable should get all users from /etc/passwd that has UID
>> >= 500 -->
>>   <local_variable id="var_at_system_accounts_allow_list"
>> comment="Accounts Allowed" datatype="string" version="1">
>>     <object_component item_field="subexpression"
>> object_ref="object_at_system_accounts_allow_list" />
>>   </local_variable>
>>
>>   <ind:textfilecontent54_object id="object_at_system_accounts_allow_list"
>> version="1">
>>     <ind:filepath>/etc/passwd</ind:filepath>
>>     <ind:pattern operation="pattern
>> match">^([^:]+):[^:]+:[\d]+:[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>
>>     <ind:instance operation="greater than or equal"
>> datatype="int">1</ind:instance>
>>     <filter action="include">state_at_system_accounts_etc_passwd</filter>
>>   </ind:textfilecontent54_object>
>>
>>   <ind:textfilecontent54_state id="state_at_system_accounts_etc_passwd"
>> version="1">
>>     <ind:filepath>/etc/passwd</ind:filepath>
>>     <ind:pattern operation="pattern
>> match">^[^:]+:[^:]+:([\d]+):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>
>>     <ind:instance operation="greater than or equal"
>> datatype="int">1</ind:instance>
>>     <ind:subexpression operation="greater than or equal"
>> datatype="int">500</ind:subexpression>
>>
>   </ind:textfilecontent54_state>
>>
>>
>>   <!-- Test to check that there is no system accounts in /etc/at.allow -->
>>   <ind:textfilecontent54_test check="all" check_existence="none_exist"
>> id="test_at_system_accounts_at_allow" comment="Testing /etc/at.allow for
>> system accounts" version="1">
>>     <ind:object object_ref="object_at_system_accounts_allow" />
>>   </ind:textfilecontent54_test>
>>
>>   <ind:textfilecontent54_object comment="/etc/at.allow"
>> id="object_at_system_accounts_allow" version="1">
>>     <!-- Get all users from /etc/at.allow -->
>>     <ind:filepath>/etc/at.allow</ind:filepath>
>>     <ind:pattern operation="pattern match">^(.+)$</ind:pattern>
>>     <ind:instance operation="greater than or equal"
>> datatype="int">1</ind:instance>
>>     <!-- Exclude root -->
>>     <filter
>> action="exclude">state_at_system_accounts_at_allow_root</filter>
>>     <!-- Exclude all user accounts -->
>>     <filter
>> action="exclude">state_at_system_accounts_at_allow_uid</filter>
>>   </ind:textfilecontent54_object>
>>
>>   <ind:textfilecontent54_state
>> id="state_at_system_accounts_at_allow_root" version="1">
>>     <ind:text>root</ind:text>
>>   </ind:textfilecontent54_state>
>>
>>   <unix:password_state id="state_at_system_accounts_at_allow_uid"
>> version="1">
>>     <unix:username var_ref="var_at_system_accounts_allow_list"
>> var_check="at least one" />
>>   </unix:password_state>
>>
>> </def-group>
>>
>> --
>> Rodolfo
>>
>> --
>> Rodolfo Martínez
>>
>> On Tue, May 31, 2016 at 5:43 PM, Rodolfo Martínez <[email protected]>
>> wrote:
>>
>>> Hi List,
>>>
>>> After many hours playing with SSG and OpenSCAP and not able to do what
>>> I want I need some help.
>>>
>>> Forgive me if I use SCAP or OpenSCAP terms incorrectly, I am new to
>>> SSG and I am still getting familiar.
>>>
>>> The following OVAL test searches for system accounts (UID < 500) in
>>> /etc/at.allow (I am showing just the relevant parts of
>>> RHEL/5/input/oval/at_system_accounts.xml to explain my problem):
>>>
>>> <criteria>
>>>   <criterion test_ref="test_at_system_accounts_at_allow" />
>>> </criteria>
>>>
>>> <unix:password_test check="all" check_existence="none_exist"
>>> comment="Testing system accounts in /etc/at.allow"
>>> id="test_at_system_accounts_at_allow" version="1">
>>>   <unix:object object_ref="object_at_system_accounts_at_allow" />
>>> </unix:password_test>
>>>
>>> <unix:password_object id="object_at_system_accounts_at_allow"
>>> version="1">
>>>   <unix:username operation="equals"
>>> var_ref="var_at_system_accounts_allow_list" var_check="at least one"
>>> datatype="string" />
>>>   <filter action="include">state_at_system_accounts_at_allow_uid</filter>
>>> </unix:password_object>
>>>
>>> <local_variable id="var_at_system_accounts_allow_list"
>>> comment="Accounts Allowed" datatype="string" version="1">
>>>   <object_component item_field="subexpression"
>>> object_ref="object_at_system_accounts_allow_list" />
>>> </local_variable>
>>>
>>> <ind:textfilecontent54_object comment="/etc/at.allow"
>>> id="object_at_system_accounts_allow_list" version="1">
>>>   <ind:filepath>/etc/at.allow</ind:filepath>
>>>   <ind:pattern operation="pattern match">^(.*)$</ind:pattern>
>>>   <ind:instance operation="greater than or equal"
>>> datatype="int">0</ind:instance>
>>> </ind:textfilecontent54_object>
>>>
>>> <unix:password_state id="state_at_system_accounts_at_allow_uid"
>>> version="1">
>>>   <unix:user_id datatype="int" operation="less than">500</unix:user_id>
>>> </unix:password_state>
>>>
>>>
>>> The test above gets the users information from the sources specified
>>> in NSS (/etc/nsswitch.conf) which is correct, however I want to create
>>> a version that uses /etc/passwd directly. Why? We have many
>>> (thousands?) of RHEL 5 based servers with LDAP integration, and many
>>> (thousands?) of accounts in the LDAP servers.
>>>
>>> Simple tests like RHEL/5/input/oval/at_system_accounts.xml and
>>> RHEL/5/input/oval/cron_system_accounts.xml can take hours to run
>>> because they retrieve *all* users information from the LDAP servers
>>> and they do it *for each entry* in /etc/at.allow and /etc/cron.allow.
>>> Also, if we run OpenSCAP (oscap) at the same time in a few servers
>>> they hit the LDAP servers really bad.
>>>
>>> I have been trying to replace password_test and password_object by
>>> textfilecontent54_test and textfilecontent54_object without any luck.
>>> If you want, I can share my at_system_accounts.xml file that I thought
>>> it was going to work.
>>>
>>> I would really appreciate any help or hint?
>>>
>>>
>>> Regards
>>> --
>>> Rodolfo Martínez
>>>
>>
>>
>> --
>> SCAP Security Guide mailing list
>> [email protected]
>>
>> https://lists.fedorahosted.org/admin/lists/[email protected]
>> https://github.com/OpenSCAP/scap-security-guide/
>>
>>
>
> --
> SCAP Security Guide mailing list
> [email protected]
>
> https://lists.fedorahosted.org/admin/lists/[email protected]
> https://github.com/OpenSCAP/scap-security-guide/
>
>
--
SCAP Security Guide mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
https://github.com/OpenSCAP/scap-security-guide/

Reply via email to