Generally, CIS Benchmarks are only prescriptive and getting near/total compliance with the benchmark is mainly for those who have host fleets under some SCAP compliance regime. Nonetheless, picking on the low hanging fruit such as cron compliance isn't going to drastically improve the security posture of the host, you still need to follow through with all the other recommendations in the benchmark.
Also worth noting is that the CIS Benchmarks evolve along the latest security practices/thinking and are subject to constant change, which may not sit comfortably with a typical OS release whose selling point is ease of providing more functionality, features and flexibility.
Hardening an OS usually has its place as a service finalisation activity i.e. it occurs well after installation, and the CIS Benchmarks remain a useful tool for doing this.
On Thu, 7 Dec 2023 at 00:21, Ondrej Pohorelsky <opohorel@xxxxxxxxxx> wrote:
--On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
> Hi everyone,
>
> For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and swap deny list for allow list. I'm not
> really sure if I should make a change proposal. I figured I'll send an
> email first and see the feedback.
>
> The driving force of this change is feedback from RHEL customers, that they
> would like to have cronie and crontabs CIS compliant out of the box. Which
> means changing some of the file permissions and swapping `cron.deny` for
> `cron.allow`. As it stands now, they have to run their own scripts or dnf
> plugin (post-transaction-actions) to ensure that each update doesn't
> overwrite the file permissions they manually set.
This CIS compliance problem is not something that is limited to cron. Their
list of hardening steps covers a wide variety of software. IOW, even if cron
were changed, presuambly such customers will need need their own scripts /
dnf plugin to fix all the other apps listed in the CIS compliance guide.
IOW, I feel like the real question here is whether the distro *as a whole*,
not cron, wants/needs to be CIS compliant out of the box, or whether it
should be explicitly an admin deployment task to enable compliance via a
plugin / script.
I'm doing this only in the scope of cronie and crontabs. Basically reacting on a few customers tickets that would welcome this change,which I wouldn't like to introduce downstream.On a distro level, this really doesn't make sense. Especially for Fedora. For RHEL? Maybe, I don't know. I'm definitely not the right personto answer this question.> `cron.d` permission change (755 → 700)
> `cron.hourly` permission change (755 → 700)
>
> *crontabs* changes:
> `crontab` permission change (644 → 600)
> `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)
The main effect of the permissions change on these files is that non-root
users can't see any env variables set against the commands scheduled to run.
The actual command lines are still all visible in the proces listing when
the command runs.
Which I think shouldn't be a problem if we don't use cron.allow default, as I wrote in my previous mail.
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
