accounts_user_dot_no_world_writable_programs has a questionable OVAL

[matejak]

Description of problem:

The rule https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/accounts/accounts-session/accounts_user_dot_no_world_writable_programs does following things:

• It searches all user's home directories, trying to identify "initialization files" using a parametric regex. This is probably fine.
• It scans the whole system to collect world-writable programs, assembles a (potentially huge) regex representing all of them, and applies the regex to initialization files.

The problem is that the regex can get too big to work very easily and the rule has to traverse and remember a lot of files. This can lead to performance issues, memory issues, and issues with the regex, which would prevent the rule from working at all. At the same time, the robustness and reliability of the rule is not 100%, so the implementation of the rule needs a closer look

This issue has been triggered by https://github.com/OpenSCAP/openscap/issues/1867 that exposed difficulties of the OpenSCAP scanner with handling of the rule.

SCAP Security Guide Version:

0.1.62

[jan-cerny]

We have found several problems with this OVAL for this rule:

• The object object_accounts_user_dot_no_world_writable_programs_init_files is written in a way that it searches in the whole sub tree starting from home directory, which might be a very large subtree. But the dot files are not located in the subdirectories, they are located right in the home directory, so we can avoid this recursion and we probably should modify the behaviors element of this object.
• the regex defined in var_user_initialization_files_regex matches not only files starting with dot eg .bashrc but also they match a substring, so they match also files test.bashrc, but these don't make effect on the configuration. Probably the regex in the variable is missing anchors (^ and $).
• the OVAL in object object_world_writable_programs browses the whole / filesystem and looks for any files that are world writable, there might be thousands of such files on a filesystem. This probably could be limited to searching only certain paths (eg. /usr/bin, ....). Maybe we could limit the search also to executable files only.

It would be also useful to investigate what happens if there are multiple users that have home directories on the system. Check whether the evaluation of object_world_writable_programs happens only once or if it happens for each user. It would be unfortunate if the object object_world_writable_programs would be evaluated for each user again and again because the evaluation of this object involves reading the whole file system.

[jan-cerny]

It scans the whole system to collect world-writable programs, assembles a (potentially huge) regex representing all of them, and applies the regex to initialization files.

Clarification: It doesn't assemble a single huge regex, instead, it creates an OVAL variable that contains a huge amount of normal-size regexes. (a vector of regexes). You can see that using verbose mode. For example on my RHEL 7 VM:

Variable 'oval:ssg-var_world_writable_programs_regex:var:1' has values "^[^#]/proc/1/task/1/attr/current", "^[^#]/proc/1/attr/exec", "^[^#]/proc/1/attr/fscreate", "^[^#]/proc/2/attr/exec", "^[^#]/proc/2/attr/fscreate", "^[^#]/proc/1/attr/current", "^[^#]/proc/2/attr/current", "^[^#]/proc/5/attr/current", "^[^#]/proc/6/attr/current", "^[^#]/proc/7/attr/current", "^[^#]/proc/8/attr/current", "^[^#]/proc/9/attr/current", "^[^#]/proc/10/task/10/attr/current", "^[^#]/proc/1/task/1/attr/keycreate", "^[^#]/proc/1/task/1/attr/sockcreate", "^[^#]/proc/2/task/2/attr/current", "^[^#]/proc/1/attr/keycreate", "^[^#]/proc/1/attr/sockcreate", "^[^#]/proc/sys/kernel/ns_last_pid", "^[^#]/proc/1/task/1/attr/exec", "^[^#]*/proc/1/task/1/attr/fscreate", ...

(I have cut this, in reality there is a lot of values).