Powered by Plus3 IT Systems

Use of sudo broken after application of “extra” hardenings (EL7)

The STIG-handlers for each of RHEL-07-020020 and RHEL-07-020023 can break ability to sudo if applied.

Note

  1. These hardenings have, historically, not been universally applied to watchmaker-hardened systems. However, they are included with the hardening contents and some watchmaker-users do choose to execute them.

  2. Use with more-recent spel AMIs may avoid the problems reported, as those AMIs already include updated SELinux-related sudoers configurations.

  • RHEL-07-020020

    Rule Title: The Red Hat Enterprise Linux operating system must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

    This handler for this STIG-ID makes sure that every local user with a uid and/or gid respectively greater than the SYS_UID_MAX and SYS_GID_MAX settings in the /etc/login.defs file has an SELinux user-confinement defined. These confinements can be viewed by executing:

    semanage login -l

    If a local user hasn’t already had a user-confinement applied, this state will apply one. The state will search relevant Pillar-data to look for confinement-mappings and apply any that are defined. The relevant Pillar data is defined in the /srv/watchmaker/salt/pillar/<ENVIRONMENT>/init.sls file under the ash-linux:lookup:sel_confine map-object.

    One can check if watchmaker is aware of this map-object by typing:

    salt-call -c /opt/watchmaker/salt pillar.get ash-linux:lookup:sel_confine

    As the root user. If execution of this command returns only:

    local:

    Then the pillar-data is not present. If pillar-data is present, then it should return a list of SELinux user-confinements and each returned confinement will have a list of one or more usernames. For example:

    # salt-call -c /opt/watchmaker/salt pillar.get ash-linux:lookup:sel_confine
local:
    |_
      ----------
      staff_u:
          - ec2-user
    |_
      ----------
      unconfined_u:
          - ssm-user

    Each username listed under a confinement will be given that confinement when RHEL-07-020020 is run.

  • RHEL-07-020023

    Rule Title: The Red Hat Enterprise Linux operating system must elevate the SELinux context when an administrator calls the sudo command.

    This handler makes sure that every user of the sudo subsystem has an SELinux privilege-transition defined. These transitions aim to make it so that when users execute sudo, they don’t have to pass any extra command-options to get the correct SELinux profile.

User Mapped As user_u

If the ash-linux:lookup:sel_confine map-object does not exist in the Pillar-data, every local user without an existing confinement will get mapped to the user_u confinement. This confinement-level will significantly restrict the things that the user-account can do, inclusive of using sudo. In the case of sudo these restrictions will manifest similarly to:

$ sudo -i
sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted
sudo: no valid sudoers sources found, quitting
sudo: setresuid() [0, 0, 0] -> [1004, -1, -1]: Operation not permitted
sudo: unable to initialize policy plugin
$

User Mapped As staff_u

If the previously-discussed pillar-data declares that a given username should be mapped to the staff_u user-confinement, execution of sudo may result in an error. A quick sudo -i will show:

$ sudo -i
-bash: /root/.bash_profile: Permission denied

Some further actions might show output similar to the following:

-bash-4.2# id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

-bash-4.2# ls -al
ls: cannot access .bashrc: Permission denied
ls: cannot access .bash_history: Permission denied
ls: cannot access .tcshrc: Permission denied
ls: cannot access .bash_profile: Permission denied
ls: cannot access .bash_logout: Permission denied
ls: cannot access install.sh: Permission denied
ls: cannot access .cshrc: Permission denied
total 24
dr-xr-x---.  6 root root 4096 Aug 17 14:35 .
dr-xr-xr-x. 19 root root 4096 Aug 17 12:51 ..
-??????????  ? ?    ?       ?            ? .bash_history
-??????????  ? ?    ?       ?            ? .bash_logout
-??????????  ? ?    ?       ?            ? .bash_profile
-??????????  ? ?    ?       ?            ? .bashrc
-??????????  ? ?    ?       ?            ? .cshrc
drwx------.  2 root root 4096 Aug 17 13:22 .ssh
-??????????  ? ?    ?       ?            ? .tcshrc

The errors are due to the sudo action selecting the default staff_u:staff_r:staff_t:s0-s0:c0.c1023 SELinux rights-mapping.

Workaround:

To work around, invoke sudo as follows:

$ sudo -i -r sysadm_r -t sysadm_t

The user should receive no SELinux errors before the root prompt is displayed, nor should they receive errors from operations like ls ${HOME}. Similarly, if they execute id -Z, they should get output similar to:

# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

User Mapped As unconfined_u

There are a few ways that users get assigned this confinement: the user was explicitly created with that confinement assigned; they login using a third-party authentication-service like Active directory; or the previously-mentioned pillar-data was configured to map them to that confinement. Typically, so-mapped users will not experience any SELinux-related permissions problems. However, if an SELinux role-transition has been defined in the sudoers subsystem (as is done when RHEL-07-020023 is run), the user may experience an error like:

$ sudo -i
sudo: unconfined_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 is not a valid context

Workaround:

To work around, invoke sudo as follows:

$ sudo -i -r unconfined_r -t unconfined_t