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 understand some organizations have no choice in whether or not they
comply with the CIS guidance - its mandated for many. At the same time
though some of the recommendations, including those for cron, are verging
on snakeoil / extreme paranoia, and as such are dubious to impose on
every users of the distro by default.
> I would like these changes for F40, as this is going to be a branching
> point for next RHEL and I would like to go with upstream first approach.
>
> *cronie* changes:
> `cron.allow` replaces `cron.deny` (file permission 600)
I don't see a functional need to create cron.allow by default
to avoid "dnf update" problems.
An admin who wants to deny non-root access to crontab can create
this cron.allow file, even if cron.deny already exists & continues
to exist, and cron.allow will take priority over cron.deny. There's
no need to actally delete cron.deny, if I'm reading the docs right:
[quote 'man crontab']
Scheduling cron jobs with crontab can be allowed or disal‐
lowed for different users. For this purpose, use the
cron.allow and cron.deny files. If the cron.allow file ex‐
ists, a user must be listed in it to be allowed to use
crontab. If the cron.allow file does not exist but the
cron.deny file does exist, then a user must not be listed
in the cron.deny file in order to use crontab. If neither
of these files exist, then only the super user is allowed
to use crontab.
[/quote]
IMHO, the CIS mandate to delete cron.deny looks dubious, and the
stated "dnf update" problem does not exist, and so does not justify
the behaviour regression for Fedora users of switching to a 'deny all'
policy by default.
> `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.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
_______________________________________________
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
