[PATCH 8/9] Added -xdev to any find commands to prevent traversing remote filesystems.

Steinke, Leland J CTR DISA FSO (US) leland.j.steinke.ctr at mail.mil
Fri Oct 26 13:27:10 UTC 2012


Perhaps the setuid file check should be run against local partitions that do not have the nosuid mount option?  See V-805 in the rhel5 content.

-Leland
________________________________________
From: scap-security-guide-bounces at lists.fedorahosted.org [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of Jeffrey Blank [blank at eclipse.ncsc.mil]
Sent: Thursday, October 25, 2012 17:26
To: scap-security-guide at lists.fedorahosted.org
Subject: Re: [PATCH 8/9] Added -xdev to any find commands to prevent traversing remote filesystems.

then your compliance check on the system hosting that filesystem should
catch it, not the 1000 clients trying to walk its filesystem.

what you should be more weary of is getting all the local partitions
when you use -xdev, such as /var, /tmp etc.


On 10/25/2012 05:21 PM, Shawn Wells wrote:
> On 10/25/12 5:11 PM, Michele Newman wrote:
>> ---
>>   RHEL6/input/system/accounts/restrictions/password_storage.xml | 2 +-
>>   RHEL6/input/system/auditing.xml                               | 4 ++--
>>   RHEL6/input/system/permissions/files.xml                      | 8
>> ++++----
>>   3 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git
>> a/RHEL6/input/system/accounts/restrictions/password_storage.xml
>> b/RHEL6/input/system/accounts/restrictions/password_storage.xml
>> index 6c1c187..153a2d6 100644
>> --- a/RHEL6/input/system/accounts/restrictions/password_storage.xml
>> +++ b/RHEL6/input/system/accounts/restrictions/password_storage.xml
>> @@ -97,7 +97,7 @@ users and should not be used.  Any <tt>.netrc</tt>
>> files should be removed.
>>   <ocil clause="any .netrc files exist">
>>   To check the system for the existence of any <tt>.netrc</tt> files,
>>   run the following command:
>> -<pre># find / -name .netrc</pre>
>> +<pre># find / -xdev -name .netrc</pre>
>>   <!-- needs fixup to limit search to home dirs -->
>>   </ocil>
>>   <rationale>
>> diff --git a/RHEL6/input/system/auditing.xml
>> b/RHEL6/input/system/auditing.xml
>> index 9599c5c..d10fb78 100644
>> --- a/RHEL6/input/system/auditing.xml
>> +++ b/RHEL6/input/system/auditing.xml
>> @@ -1166,7 +1166,7 @@ these events could serve as evidence of
>> potential system compromise.</rationale>
>>   <description>At a minimum the audit system should collect the
>>   execution of privileged commands for all users and root.
>>   To find the relevant setuid programs:
>> -<pre># find / -type f -perm -4000 -o -perm -2000 2>/dev/null</pre>
>> +<pre># find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null</pre>
>>   Then, for each setuid program on the system, add a line of the
>> following form to
>>   <tt>/etc/audit/audit.rules</tt>, where <i>SETUID_PROG_PATH</i> is
>> the full path to each setuid program
>>   in the list:
>> @@ -1174,7 +1174,7 @@ in the list:
>>   </description>
>>   <ocil clause="it is not the case">
>>   To verify that auditing of privileged command use is configured, run
>> the following command to find relevant setuid programs:
>> -<pre># find / -type f -perm -4000 -o -perm -2000 2>/dev/null</pre>
>> +<pre># find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null</pre>
>>   Run the following command to verify entries in the audit rules for
>> all programs found with the previous command:
>>   <pre># grep path /etc/audit/audit.rules</pre>
>>   It should be the case that all relevant setuid programs have a line
>> in the audit rules.
>> diff --git a/RHEL6/input/system/permissions/files.xml
>> b/RHEL6/input/system/permissions/files.xml
>> index b8c3871..44dabe8 100644
>> --- a/RHEL6/input/system/permissions/files.xml
>> +++ b/RHEL6/input/system/permissions/files.xml
>> @@ -313,7 +313,7 @@ following command:
>>   </description>
>>   <ocil clause="any world-writable directories are missing the sticky
>> bit">
>>   To find world-writable directories that lack the sticky bit, run the
>> following command:
>> -<pre># find / -type d -perm 002 ! -perm 1000</pre>
>> +<pre># find / -xdev -type d -perm 002 ! -perm 1000</pre>
>>   </ocil>
>>   <rationale>
>>   Failing to set the sticky bit on public directories allows
>> unauthorized users to delete files in the directory structure.
>> @@ -345,7 +345,7 @@ symptoms of a misconfigured application or user
>>   account.</description>
>>   <ocil clause="there is output">
>>   To find world-writable files, run the following command:
>> -<pre># find / -type f -perm -002</pre>
>> +<pre># find / -xdev -type f -perm -002</pre>
>>   </ocil>
>>   <ident cce="3795-2" />
>>   <ref nist="CM-6"/>
>> @@ -361,7 +361,7 @@ of any unpackaged SGID files.
>>   </description>
>>   <ocil clause="there is output">
>>   To find world-writable files, run the following command:
>> -<pre># find / -type f -perm -002</pre>
>> +<pre># find / -xdev -type f -perm -002</pre>
>>   </ocil>
>>   <rationale>Executable files with the SGID permission run with the
>> privileges of
>>   the owner of the file. SGID files of uncertain provenance could
>> allow for
>> @@ -382,7 +382,7 @@ of any unpackaged SUID files.
>>   </description>
>>   <ocil>
>>   To find world-writable files, run the following command:
>> -<pre># find / -type f -perm -002</pre>
>> +<pre># find / -xdev -type f -perm -002</pre>
>>   </ocil>
>>   <rationale>Executable files with the SUID permission run with the
>> privileges of
>>   the owner of the file. SUID files of uncertain provenance could
>> allow for
>
> I'm still a little weary of this. What happens if a SUID or improperly
> chmod'd file exists on a non-local filesystem?
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


More information about the scap-security-guide mailing list