On 5/21/14 5:47 AM, Jan Lieskovsky wrote:
----- Original Message -----
From: "Paul Tittle" <[email protected]>
To: [email protected]
Sent: Tuesday, May 20, 2014 9:24:44 PM
Subject: [PATCH] exclude proc/selinux files from world_writeable_files
The following commit in openscap causes proc to be considered a 'local'
filesystem.
---
commit a9d98d697d85cb7f26c615543276e042c9749af0
Author: Tomas Heinrich <[email protected]>
Date: Tue Nov 12 11:01:21 2013 +0100
OVAL: change the algo used to distinguish 'local' and 'remote' fs
With 'local', fts now descends into /proc and /sys, among others,
which were previously excluded. This can cause performance issues.
---
The 'world_writeable_files' test will fail if a world-writeable
regular file is found. So we must mask out /proc files with a filter.
I did a `find / -perm -002 -type f` and also found some 'special' files
in /selinux that are world-writeable and type f, so a filter has been
added for those too.
Just to explicitly see the performance difference / gain / improvement
for that rule.
Unpatched:
----------
# time oscap oval eval --id oval:ssg:def:1086 ssg-rhel6-oval.xml
Definition oval:ssg:def:1086: false
Evaluation done.
real 0m14.138s
user 0m7.327s
sys 0m2.590s
Patched:
--------
# time oscap oval eval --id oval:ssg:def:1086 ssg-rhel6-oval-patched.xml
Definition oval:ssg:def:1086: true
Evaluation done.
real 0m8.038s
user 0m6.783s
sys 0m1.232s
=> ACK, thank you for the patch.
Btw. (IMHO) another good candidate for exclusion is /sys filesystem due the
reasons
outlined below:
* it should be considered as dump of kernel data structures, their attributes
(& linkage
between them) to userspace (from
https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt) =>
as such there shouldn't be reason / need why even administrator should want
to update file
permissions on the files under that subdirectory (if the permissions should
be changed, it's
bug of the package / kernel module creating that file, and it should be
reported)
* change of permissions (even when performed as root) from user-space holds
only till the
next reboot (if not implemented via the particular module directly) => even
the fix would
be only temporary
* last, but not least, /sys contains lot of symlink loops, which by themselves
might cause the
scanner to enter such infinite loop => IMHO I would propose /sys filesystem
to be excluded from
scan too (just margin note).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
---
...ile_permissions_unauthorized_world_writable.xml | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git
a/RHEL/6/input/checks/file_permissions_unauthorized_world_writable.xml
b/RHEL/6/input/checks/file_permissions_unauthorized_world_writable.xml
index 599ad98..c3d4c8a 100644
--- a/RHEL/6/input/checks/file_permissions_unauthorized_world_writable.xml
+++ b/RHEL/6/input/checks/file_permissions_unauthorized_world_writable.xml
@@ -23,9 +23,17 @@
<unix:path operation="equals">/</unix:path>
<unix:filename operation="pattern match">^.*$</unix:filename>
<filter
action="include">state_file_permissions_unauthorized_world_write</filter>
+ <filter
action="exclude">state_file_permissions_unauthorized_world_write_exclude_special_selinux_files</filter>
+ <filter
action="exclude">state_file_permissions_unauthorized_world_write_exclude_proc</filter>
</unix:file_object>
<unix:file_state id="state_file_permissions_unauthorized_world_write"
version="1">
<unix:type operation="equals">regular</unix:type>
<unix:owrite datatype="boolean">true</unix:owrite>
</unix:file_state>
+ <unix:file_state
id="state_file_permissions_unauthorized_world_write_exclude_special_selinux_files"
version="1">
+ <unix:filepath operation="pattern
match">^/selinux/(?:(?:member)|(?:user)|(?:relabel)|(?:create)|(?:access)|(?:context))$</unix:filepath>
+ </unix:file_state>
+ <unix:file_state
id="state_file_permissions_unauthorized_world_write_exclude_proc"
version="1">
+ <unix:filepath operation="pattern match">^/proc/.*$</unix:filepath>
+ </unix:file_state>
</def-group>
--
1.7.1
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Thanks for ack, Jan. Pushed.
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
