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):
<criterion test_ref="test_at_system_accounts_at_allow" />
<unix:password_test check="all" check_existence="none_exist"
comment="Testing system accounts in /etc/at.allow"
<unix:object object_ref="object_at_system_accounts_at_allow" />
<unix:password_object id="object_at_system_accounts_at_allow" version="1">
var_ref="var_at_system_accounts_allow_list" var_check="at least one"
comment="Accounts Allowed" datatype="string" version="1">
<ind:pattern operation="pattern match">^(.*)$</ind:pattern>
<ind:instance operation="greater than or equal"
<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>
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?
I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.