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 <opoho...@redhat.com> wrote:
>
>
> On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé <berra...@redhat.com>
> 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 person
> to 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.
>
> --
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat <https://www.redhat.com>
>
> opoho...@redhat.com
> <https://www.redhat.com>
> --
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
