Hi Robert,
Thanks for your reply.
That perfectly works in a bash remediation script, but how do I do that
with OVAL without using '<unix:password_object>' ?
--
Rodolfo Martínez
On Wed, Jun 8, 2016 at 12:19 PM, Hayden,Robert <RHAYDEN(a)cerner.com> wrote:
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(a)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(a)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(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/
<
https://urldefense.proofpoint.com/v2/url?u=http-3A__code.google.com_p_nss...
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.o...
https://github.com/OpenSCAP/scap-security-guide/
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSCAP_...
--
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.o...
https://github.com/OpenSCAP/scap-security-guide/
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSCAP_...
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.
--
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/