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(a)gmail.com> wrote:
A totally different approach to addressing your issue would be to
use
nss_db or
http://code.google.com/p/nsscache/ to cache LDAP.
On Tue, May 31, 2016 at 4:43 PM, Rodolfo Martínez <rmtzcx(a)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(a)lists.fedorahosted.org
>
>
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedo...
>
https://github.com/OpenSCAP/scap-security-guide/
>
--
Andrew Shewmaker
--
SCAP Security Guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedo...
https://github.com/OpenSCAP/scap-security-guide/