DISA STIG hardening results in inability to run commands using cron

[Philip Roche]

We have a Ubuntu 20.04 cloud image with DISA STIG hardening applied but we are unable to run commands as cron they fail with permission denied error.

Reproducer:

```
# Set up a cron job 2m from current time (pls don't run this at xx:58 or xx:59 :))
cat > /etc/cron.d/test << EOF
$(( $(date +%M) + 2)) $(date +%H) * * * root echo "Hello" > /tmp/hello
EOF
# Restart cron to clear logs
systemctl restart cron
# Wait 2m
journalctl -t cron
```

You will see `Permission denied` in the journalctl output.

```
# Mar 23 21:53:01 alatl15-gpcbm06 cron[533877]: (*system*test) RELOAD (/etc/cron.d/test)
# Mar 23 21:53:01 alatl15-gpcbm06 cron[534993]: Permission denied
```

We have tracked this down to the hardening changes applied to /etc/pam.d/common-auth in rule id xccdf_org.ssgproject.content_rule_smartcard_pam_enabled.

```
ensure_pam_module_options '/etc/pam.d/common-auth' 'auth' '[success=2 default=ignore]' 'pam_pkcs11.so' '' '' ''
```

If this last line of /etc/pam.d/common-auth is commented out and cron restarted then it runs no problem.

Is this expected when this rule is remediated?

[Adam Bell (arbell)]

Hi Phil,

Like LP#1969480, this also seems to be a bug in the way that the CaC scripts handle pam.d files.

The STIG hardening probably added three lines to the bottom of /e/p.d/common-auth.

As an immediate workaround, you can move those three lines ("auth required pam_faildelay", "auth required pam_tally2", "auth [...] pam_pkcs11") above the "auth requisite pam_deny" line. This resolves the issue that you described on my side; please let me know whether this resolves the issue (short-term) on your side.

We'll take a look at the `ensure_pam_module_options` function in the CaC content to generate long-term resolutions to this issue and LP#1969480!

[Philip Roche (philroche)]

Your suggested workaround worked.

After suggested modification `/etc/pam.d/common-auth` now reads.

```
# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok
# here's the fallback if no module succeeds
auth required pam_faildelay.so delay=4000000
auth required pam_tally2.so deny=3 onerr=fail
auth [success=2 default=ignore] pam_pkcs11.so
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config
```

Before modification `/etc/pam.d/common-auth`:

```
# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_cap.so
# end of pam-auth-update config
auth required pam_faildelay.so delay=4000000
auth required pam_tally2.so deny=3 onerr=fail
auth [success=2 default=ignore] pam_pkcs11.so
```

[Adam Bell (arbell)]

Hi Phil,

A fix for this was created by ebarretto and has been merged into our tooling at https://github.com/canonical/ComplianceAsCode-content/pull/272.

We will let you know once the fix has been released!

[Adam Bell (arbell)]

Hi Phil,

This has been released in ubuntu-security-guides-enhanced version 20.04.15!