Incorrect permissions with `5.1.8 | Ensure at/cron is restricted to authorized users` task about ubuntu18-cis HOT 2 CLOSED

Hello,
Thanks for raising the issue and I can make the change but I want to make sure I fully understand the mistake being made before the change. I have the audit from the and remediation from that control in the benchmark below. Looking at the audit output that is being used as the "good" finding it is set to 640. Then in the remediation step it has you removing write and execute from group and read/write/execute from other. Doing it by the number I think 640 is correct for those files since in the end the user perms are left with whatever, group is left with only read permissions, and other has none. Let me know if I'm mis-interpreting the control.

audit section:
Run the following command and verify Uid and Gid are both 0/root and Access, does not grant write or execute to group, and does not grant permissions to other for/etc/cron.allow: # stat /etc/cron.allow Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)

remediation section:
chmod g-wx,o-rwx /etc/cron.allow

George

from ubuntu18-cis.

Ah I see the issue, I was comparing the Distribution Independent Linux CIS Benchmark instead of the Ubuntu-specific CIS Benchmark.

In the DIL benchmark the 5.1.8 criteria requires 0600 permissions for the at/cron files, whereas in the Ubuntu benchmark the 5.1.8 criteria calls for 0640 permissions.

Not entirely sure why the difference in permissions, but AFAICT it seems that Debian/Ubuntu systems need the 640 permissions due to the crontab group needing access to read the at/cron files to properly restrict user access.

ie.

• https://bugs.launchpad.net/ubuntu/+source/bastille/+bug/55741
• https://groups.google.com/g/comp.os.linux.security/c/Z1-dOm8YegI

from ubuntu18-cis.