"oscap-ssh --sudo" fails to retrieve the result files with "scp: ...: Permission denied" error

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux (RHEL) 7 and later
    • openscap-utils

Issue

  • When executing oscap-ssh with --sudo option, the command fails to retrieve the result files, as shown in the example below

    # oscap-ssh --sudo user@system 22 xccdf eval ... --report report.html ...
[...]
oscap exit code: 0
Copying back requested files...
scp: /tmp/tmp.XXX/report.html: Permission denied
Failed to copy the HTML report back to local machine!

Resolution

Workaround - Use your own oscap-ssh tool fixing the issue

There is no available workaround except fixing the oscap-ssh utility (modifying the system's umask is probably not an option ...).
To achieve this, perform the following operations.

  1. Copy the shipped /usr/bin/oscap-ssh binary onto /usr/local/bin

    # cp /usr/bin/oscap-ssh /usr/local/bin

  2. Modify /usr/local/bin/oscap-ssh as shown below

    • Original code block (from RHEL 7)

      ssh -o ControlPath="$MASTER_SOCKET" $SSH_ADDITIONAL_ARGS -p "$SSH_PORT" "$SSH_HOST" "$OSCAP_SUDO oscap ${args[*]}"

    • Modified code block in

      if [ -z "$OSCAP_SUDO" ]; then
	ssh -o ControlPath="$MASTER_SOCKET" $SSH_ADDITIONAL_ARGS -p "$SSH_PORT" "$SSH_HOST" "oscap ${args[*]}"
else
	ssh -o ControlPath="$MASTER_SOCKET" $SSH_ADDITIONAL_ARGS -p "$SSH_PORT" "$SSH_HOST" "$OSCAP_SUDO /bin/sh -c 'oscap ${args[*]}; rc=\$?; chown     \${SUDO_USER} $REMOTE_TEMP_DIR/*; exit \$rc'"
fi

Root Cause

  • oscap-ssh uses the standard scp command running as the target user to retrieve the result files from temporary directory /tmp/tmp.XXX/ created by oscap while executing as the root user
  • If the umask has been modified in /etc/bashrc, it may happen that the files in temporary directory /tmp/tmp.XXX/ are only readable by the root user, causing the issue

Diagnostic Steps

  • Check that the umask for the user is altered when executing a non-interactive shell

    $ ssh user@system 'bash -c umask'
0007

    In the example above, the umask has been changed, since default value (as set in /etc/bashrc is 0002 instead, which is less restrictive).

  • Check the bash configuration files if the umask has been modified from standard umask (e.g. *022) to some more restrictive umask (e.g. 027)

    # grep -r -C 2 -w "umask" /etc/bashrc /etc/profile /etc/profile.d ~user/.bash_profile ~user/.bashrc
/etc/bashrc-    }
/etc/bashrc-
/etc/bashrc:    # By default, we want umask to get set. This sets it for non-login shell.
/etc/bashrc-    # Current threshold for system reserved uid/gids is 200
/etc/bashrc-    # You could check uidgid reservation validity in
/etc/bashrc-    # /usr/share/doc/setup-*/uidgid file
/etc/bashrc-    if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
/etc/bashrc:       umask 007
/etc/bashrc-    else
/etc/bashrc:       umask 022
/etc/bashrc-    fi
/etc/bashrc-
--
/etc/profile-export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL
/etc/profile-
/etc/profile:# By default, we want umask to get set. This sets it for login shell
/etc/profile-# Current threshold for system reserved uid/gids is 200
/etc/profile-# You could check uidgid reservation validity in
/etc/profile-# /usr/share/doc/setup-*/uidgid file
/etc/profile-if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
/etc/profile:    umask 002
/etc/profile-else
/etc/profile:    umask 022
/etc/profile-fi
/etc/profile-

    In the example above, the umask for standard users has been modified from 002 to 007 (rw------- when creating files) in /etc/bashrc, preventing the user to retrieve any file created by root after sudo is called, as shown in the example below:

    $ ssh user@system 'sudo bash -c "touch /tmp/foo && ls -l /tmp/foo"'
-rw-------. 1 root root 0 Feb 17 08:44 /tmp/foo

    Note that normally no other files than /etc/bashrc are sourced when the shell is non-interactive. Still administrators may change this default behaviour by modifying files in /etc/profile.d or not taking care of having an empty PS1 variable, the latter being used to detect non-interactivity.

SBR
Product(s)
Components
Category

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.