ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.22k stars 698 forks source link

OVAL, Bash and Ansible artifacts for accounts_umask_etc_bashrc consider all umask occurrences in /etc/bashrc #4651

Closed ggbecker closed 5 years ago

ggbecker commented 5 years ago

Description of problem:

OVAL, Bash and Ansible artifacts for accounts_umask_etc_bashrc check/remediate all occurrences of umask. That means if one applies a manual fix such as:

sed -i "/umask/s/002/027/" /etc/bashrc

which changes only the first occurrence of umask 002, will led openscap to fail because the OVAL check looks for all occurrences of umask in such file (which can contain multiple entries of umask):

https://github.com/ComplianceAsCode/content/blob/3ea35b6431430e81fdf9303fc58598454999b3ca/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_bashrc/oval/shared.xml#L21-L22

This excerpt from /etc/bashrc:

    # By default, we want umask to get set. This sets it for non-login shell.
    # Current threshold for system reserved uid/gids is 200
    # You could check uidgid reservation validity in
    # /usr/share/doc/setup-*/uidgid file
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
       umask 002
    else
       umask 022
    fi

shows us that etc/bashrc file contains by default contains multiple occurrences of umask. It's hard to handle this file because it is bash file, so a line entry can mean many things. Differently from a configuration file which it is possible to infer some patterns.

It needs investigation if it's ok to set all occurrences to the same umask value. Otherwise OVAL,Bash, Ansible should be updated to check only the occurrence which met the condition

if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then

SCAP Security Guide Version:

0.1.45

Operating System Version:

RHEL8

Steps to Reproduce:

1.sed -i "/umask/s/002/027/" /etc/bashrc

  1. oscap xccdf eval --profile ospp --rule xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc ssg-rhel8-ds.xml

Actual Results:

Title Ensure the Default Bash Umask is Set Correctly Rule xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc Ident CCE-81036-6 Result fail

Expected Results:

Title Ensure the Default Bash Umask is Set Correctly Rule xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc Ident CCE-81036-6 Result pass

Addition Information/Debugging Steps:

This problem probably applies to other rules from the group: https://github.com/ComplianceAsCode/content/tree/master/linux_os/guide/system/accounts/accounts-session/user_umask

ggbecker commented 5 years ago

Additional info:

distinction between users and daemons:

  sed -i "/umask/s/002/027/" /etc/profile
  sed -i "/umask/s/002/027/" /etc/bashrc
  sed -i "/umask/s/002/027/" /etc/csh.cshrc

with, for example, /etc/profile having this:

  if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
      umask 002
  else
      umask 022
  fi

(daemons are presumed to have "system" UID, eg. below 1000)

This leaves daemons with the default of 022.

On the SCAP side, this is not as sophisticated, the remediation scripts,
IIRC, just plow through /etc/profile and similar and replace any umask
occurences with the one specified.

Lacking the SCAP development time, this might be okay as long as it
doesn't break any daemons. Though testing that might be more work than
just changing the remediation and OVAL to check more smarter.
ggbecker commented 5 years ago

It looks like it is not a bug:

sed -i '/umask/{s/002/027/;s/022/027/}' /etc/profile /etc/bashrc /etc/csh.cshrc

Change everything to 027 seems to cause no harm.