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 rmtzcx@gmail.com 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:textroot</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 rmtzcx@gmail.com 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 scap-security-guide@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

One extra comment - should the UID of 500 be hardcoded here or should it be pulled from /etc/login.defs, or the equivalent file for other distros? I know the breakpoint between system and regular user ids has changed over the years.

-Rob

________________________________ From: Rodolfo Martínez [rmtzcx@gmail.com] Sent: Wednesday, June 08, 2016 12:32 PM To: SCAP Security Guide Subject: EXTERNAL: Re: Use /etc/passwd directly instead of sources in NSS

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 <redhatrises@gmail.commailto:redhatrises@gmail.com> 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 <rmtzcx@gmail.commailto:rmtzcx@gmail.com> 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:textroot</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 <rmtzcx@gmail.commailto:rmtzcx@gmail.com> 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 scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

Scanned by Forcepoint Email Security Gateway Click herehttps://esgpem.websense.com:443/pem/pages/digestProcess/digestProcess.jsf?content=c3805c5951889c5ec510bd913f336b3d1716d47d93b4ee10de04a78ef6c7fad82c0fe0e50f83ec29c6a066df750951d5228a8058902795e94fa86cc7c6e69f2b33db2c1092e76d7b08eb7b8efb3eb0469156ac51527d5859e4eec74d3f30db2c025e307ff8039af00030da46facf08e6a4fafe3343d12f0fe2fa51f5888792eab91860bb1b740d2cf63c0992c0430e8b to report this email as spam

​Hi Gabe.

Thanks for your suggestion! I believe it could work! I will do some testing. I will prefix the second subexpression with '?:' to avoid capture and just get the usernames.

<ind:pattern operation="pattern match">^([^:]+):[^:]+:(?:[5-9][\d][\d]|[1-9][\d]{3,}):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern>

​Thanks again​

-- Rodolfo Martínez

On Wed, Jun 8, 2016 at 1:12 PM, Gabe Alford redhatrises@gmail.com wrote:

Hi Rodolfo,

What about this?

<ind:textfilecontent54_object id="object_at_system_accounts_allow_list" version="1"> ind:filepath/etc/passwd</ind:filepath> <ind:pattern operation="pattern match">^([^:]+):[^:]+:([5-9][\d][\d]|[1-9][\d]{3,}):[\d]+:[^:]*:[^:]+:[^:]*$</ind:pattern> <ind:instance operation="greater than or equal" datatype="int">1</ind:instance> </ind:textfilecontent54_object>

Is that what you are after? It should get the usernames that are greater than or equal to 500.

Gabe

On Wed, Jun 8, 2016 at 10:32 AM, Rodolfo Martínez rmtzcx@gmail.com wrote:

...

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 redhatrises@gmail.com 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 rmtzcx@gmail.com 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:textroot</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 rmtzcx@gmail.com 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 scap-security-guide@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org

https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/

awk -F : '$3 >= 500 {print $1}' /etc/passwd

Works as well ;-)

From: Brent Kimberley

From: Rodolfo Martínez [mailto:rmtzcx@gmail.com] 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

THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

If it helps, you can use the following type of command to pull lines from /etc/passwd.

awk -v UID=500 -F: '($3>=UID)' /etc/passwd

Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | rhayden@cerner.commailto:rhayden@cerner.com | www.cerner.com

From: Rodolfo Martínez [mailto:rmtzcx@gmail.com] Sent: Wednesday, June 08, 2016 12:10 PM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Re: Use /etc/passwd directly instead of sources in NSS

Hi Andrew, I took a look at nsscache, it looks good. In fact, a combination of nsscache and nss_db might be a good solution, but not feasible at the moment. If I would be able to get a list of users from /etc/passwd with UID greater or equal to 500 without using password_object (this is the one that pulls all information from LDAP) it would be the best solution now. I will continue trying to do it. I would appreciate any hint or someone that confirm that it is not possible. Thanks

-- Rodolfo Martínez

On Tue, Jun 7, 2016 at 3:50 PM, Andrew Shewmaker <agshew@gmail.commailto:agshew@gmail.com> wrote: A totally different approach to addressing your issue would be to use nss_db or http://code.google.com/p/nsscache/https://urldefense.proofpoint.com/v2/url?u=http-3A__code.google.com_p_nsscache_&d=CwMFaQ&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=pcwthFLSIb1FyPPQL7XXkTecodKzG6MR3nJo7QVErn0&m=PthllYhhJJPJCTo_YF6BnJGba0a8t1WMIQMNJWJfvYk&s=MHS_KaNgb-TRsRZWJRSD787D8HI4cc4Idz3FLnJEUZg&e= to cache LDAP.

On Tue, May 31, 2016 at 4:43 PM, Rodolfo Martínez <rmtzcx@gmail.commailto:rmtzcx@gmail.com> 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 scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah...https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=CwMFaQ&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=pcwthFLSIb1FyPPQL7XXkTecodKzG6MR3nJo7QVErn0&m=PthllYhhJJPJCTo_YF6BnJGba0a8t1WMIQMNJWJfvYk&s=L7UIwwWoPqWWC49ftaBhBJF8zqTvXnQGQY8FobcK4Fg&e= https://github.com/OpenSCAP/scap-security-guide/https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSCAP_scap-2Dsecurity-2Dguide_&d=CwMFaQ&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=pcwthFLSIb1FyPPQL7XXkTecodKzG6MR3nJo7QVErn0&m=PthllYhhJJPJCTo_YF6BnJGba0a8t1WMIQMNJWJfvYk&s=oVEZSQZn_8ADB9oCSRWmMS_M7DRSSA829Y9t31bH5Es&e=

-- Andrew Shewmaker

-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah...https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=CwMFaQ&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=pcwthFLSIb1FyPPQL7XXkTecodKzG6MR3nJo7QVErn0&m=PthllYhhJJPJCTo_YF6BnJGba0a8t1WMIQMNJWJfvYk&s=L7UIwwWoPqWWC49ftaBhBJF8zqTvXnQGQY8FobcK4Fg&e= https://github.com/OpenSCAP/scap-security-guide/https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSCAP_scap-2Dsecurity-2Dguide_&d=CwMFaQ&c=NRtzTzKNaCCmhN_9N2YJR-XrNU1huIgYP99yDsEzaJo&r=pcwthFLSIb1FyPPQL7XXkTecodKzG6MR3nJo7QVErn0&m=PthllYhhJJPJCTo_YF6BnJGba0a8t1WMIQMNJWJfvYk&s=oVEZSQZn_8ADB9oCSRWmMS_M7DRSSA829Y9t31bH5Es&e=

CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.