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 [[email protected]] 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 <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected]<mailto:[email protected]> https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/ Scanned by Forcepoint Email Security Gateway Click here<https://esgpem.websense.com:443/pem/pages/digestProcess/digestProcess.jsf?content=c3805c5951889c5ec510bd913f336b3d1716d47d93b4ee10de04a78ef6c7fad82c0fe0e50f83ec29c6a066df750951d5228a8058902795e94fa86cc7c6e69f2b33db2c1092e76d7b08eb7b8efb3eb0469156ac51527d5859e4eec74d3f30db2c025e307ff8039af00030da46facf08e6a4fafe3343d12f0fe2fa51f5888792eab91860bb1b740d2cf63c0992c0430e8b> to report this email as spam
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
