```{eval-rst}
.. image:: ../images/cropped-plus3it-logo-cmyk.png
:width: 140px
:alt: Powered by Plus3 IT Systems
:align: right
:target: https://www.plus3it.com
```
# 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.
```{eval-rst}
.. 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//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
~~~