Re: Change of cronie and crontabs CIS compliance

[Tomáš Mráz]

Thank you very much for considering this and dropping this Change.

Regards,

Tomas Mraz
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

Thank you for your feedback.

After some thinking, I've decided to not start the Fedora Change process,
nor to merge these changes.
These changes are not suited for Fedora use cases.

Once again, I appreciate the discussion

On Tue, Dec 19, 2023 at 7:14 PM Tomáš Mráz  wrote:

> In my opinion none of these permission changes make any sense for
> installations that aren't guided by some mostly much more strict
> requirements than those for the Fedora workstations or other general
> installations of Fedora. They simply should not be applied.
>
> Removing the setuid bit from the crontab command is simply wrong as it
> breaks crontab for regular users.
>
> I do not even know why the /var/spool/anacron/cron.* permissions on the
> ghost files should be set to executable by owner - there is no point doing
> that as that makes the permissions more allowing than they currently are.
>
> And making /etc/cron.d and /etc/cron.hourly unreadable to anybody else
> than root will break the possibility to examine what would be the next job
> run by the cronnext command.
> --
> ___
> 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
>


-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Tomáš Mráz]

In my opinion none of these permission changes make any sense for installations 
that aren't guided by some mostly much more strict requirements than those for 
the Fedora workstations or other general installations of Fedora. They simply 
should not be applied.

Removing the setuid bit from the crontab command is simply wrong as it breaks 
crontab for regular users.

I do not even know why the /var/spool/anacron/cron.* permissions on the ghost 
files should be set to executable by owner - there is no point doing that as 
that makes the permissions more allowing than they currently are.

And making /etc/cron.d and /etc/cron.hourly unreadable to anybody else than 
root will break the possibility to examine what would be the next job run by 
the cronnext command.
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Petr Lautrbach]

Ondrej Pohorelsky  writes:

> I've removed cron.allow from my PR[0] and reverted to cron.deny approach.
> As this was the only disputed change in these PRs so far, I plan on merging
> both of them into rawhide at the end of this week.
> However, if you see any issue with merging this "middle ground" change,
> feel free to discuss.
>

```
- %attr(4755,root,root) %{_bindir}/crontab
+ %attr(600,root,root) %{_bindir}/crontab
```

From
https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/monitoring-and-automation/Automating_System_Tasks/

"""
To create a crontab as a specific user, login as that user and type the
command crontab -e to edit the user’s crontab with the editor specified
in the VISUAL or EDITOR environment variable.
"""

If you want to change this you should push the change via Fedora
Change process so it's clearly announced and documented.





> [0]https://src.fedoraproject.org/rpms/cronie/pull-request/12
>
> On Sun, Dec 10, 2023 at 3:37 PM Chuck Anderson  wrote:
>
>> On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
>> > 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.
>>
>> I think this part alone is worthwhile in a general distro like Fedora,
>> irrespective of any CIS requirements.  Env vars can contain secret
>> data and they are no longer readble by all users in process lists, so
>> changing permissions on cron files fixes a real potential information
>> leak.
>>
>> Also, it is hard to keep file and directory permissions changed from
>> how they are packaged.  The files will become exposed during package
>> updates until some other script comes by and fixes them again.  So it
>> is worthwhile to fix this in the packaging.
>>
>> I agree that the correct middle ground is to fix the permissions, but
>> leave the other parts about cron.allow/cron.deny alone.
>> --
>> ___
>> 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
>>
>
>
> -- 
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat 
>
> opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

I've removed cron.allow from my PR[0] and reverted to cron.deny approach.
As this was the only disputed change in these PRs so far, I plan on merging
both of them into rawhide at the end of this week.
However, if you see any issue with merging this "middle ground" change,
feel free to discuss.

[0]https://src.fedoraproject.org/rpms/cronie/pull-request/12

On Sun, Dec 10, 2023 at 3:37 PM Chuck Anderson  wrote:

> On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
> > 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.
>
> I think this part alone is worthwhile in a general distro like Fedora,
> irrespective of any CIS requirements.  Env vars can contain secret
> data and they are no longer readble by all users in process lists, so
> changing permissions on cron files fixes a real potential information
> leak.
>
> Also, it is hard to keep file and directory permissions changed from
> how they are packaged.  The files will become exposed during package
> updates until some other script comes by and fixes them again.  So it
> is worthwhile to fix this in the packaging.
>
> I agree that the correct middle ground is to fix the permissions, but
> leave the other parts about cron.allow/cron.deny alone.
> --
> ___
> 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
>


-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Chuck Anderson]

On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
> 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.

I think this part alone is worthwhile in a general distro like Fedora,
irrespective of any CIS requirements.  Env vars can contain secret
data and they are no longer readble by all users in process lists, so
changing permissions on cron files fixes a real potential information
leak.

Also, it is hard to keep file and directory permissions changed from
how they are packaged.  The files will become exposed during package
updates until some other script comes by and fixes them again.  So it
is worthwhile to fix this in the packaging.

I agree that the correct middle ground is to fix the permissions, but
leave the other parts about cron.allow/cron.deny alone.
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Arthur G]

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  wrote:

>
>
> On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé 
> 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 
>
> opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé 
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 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 1:02 PM Daniel P. Berrangé 
wrote:

> On Wed, Dec 06, 2023 at 11:53:26AM +, Tom Hughes via devel wrote:
> > On 06/12/2023 11:08, Ondrej Pohorelsky wrote:
> >
> > > The only difference is that if you have populated the cron.deny list,
> > > after update it gets saved as .rpmsave and cron.allow is created.
> > > If the cron.deny is blank, it will get replaced.
> > > Also, if you had cron.allow populated before, it will stay this way and
> > > blank cron.allow.rpmnew is created.
> >
> > Surely there is one more change though?
> >
> > Namely that users who could previously run crontab to create
> > cron jobs can no longer do so unless they have been added to
> > the cron.allow file.
> >
> > That seems like a breaking change to me?
>
> Yes, making cron unusable out of the box for non-root users feels like
> an pretty major regression in behaviour.
>


Yes, you are right. Thank you for noticing this. I've focused on the file
permissions and completely overlooked this.

I think we can leave cron.deny approach as the Fedora default and change
the file permissions to be CIS compliant.
As, the real pain point that customers stated isn't the creation of
cron.allow, but file permissions that change after each update.
IMO, this can be a good middle ground.

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Nikos Mavrogiannopoulos]

On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé  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 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 think you set the right question there. With the cybersecurity
regulatory trend on EU and US, almost all organizations need to comply
with a secure configuration / hardening scheme like CIS. The main
reason is that if you want to follow any respectable security path
that puts the org on the due care set, you need to ensure that your
systems are configured securely, meaning no more options than the
necessary are enabled on the system. The CIS benchmarks provide that.

Now applying the benchmark can be pretty complex as some of the rules
CIS prohibits are required by some organizations because they run
(e.g.) on the cloud that requires it, but others on a different
environment do not. The question you set is, to the point and useful.
Even if the default installation doesn't follow CIS closely, but
provides a better balance of usability and security based on the CIS
guidelines, it will add value to Fedora derivatives -both by reducing
the default attack surface and by making the more advanced hardening
easier-.

Regards,
Nikos
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

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@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

Re: Change of cronie and crontabs CIS compliance

[Stephen Smoogen]

On Wed, 6 Dec 2023 at 06:49, Ondrej Pohorelsky  wrote:

>
>
> On Wed, Dec 6, 2023 at 12:39 PM Fabio Valentini 
> wrote:
>
>> On Wed, Dec 6, 2023 at 11:17 AM 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.
>>
>> Just out of curiosity - what does CIS even stand for?
>> The linked Red Hat docs don't expand the acronym, and googling for it
>> obviously yields results for something entirely different
>>
>
> Basically, it is a Center for Internet Security (CIS) benchmark that some
> companies use as a reference to limit configuration-based security
> vulnerabilities.
> I'm not really sure, but I think some governments require that their
> systems are compliant.
>
>

This standard is used in various Universities, local governments,
hospitals, financial organizations, and can be required in some cases for
PCI compliance (if your acreditor likes that kind of thing). Basically it
is one of the major standards like the US DOD STIG
https://en.wikipedia.org/wiki/Security_Technical_Implementation_Guide  /
https://ncp.nist.gov/repository

Like any standard, there are things which are good and some which are 'that
is a choice you could make, but...'



> You can look at CIS wikipedia page for more info:
>
> https://en.wikipedia.org/wiki/Center_for_Internet_Security#CIS_Controls_and_CIS_Benchmarks
>
> --
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat 
>
> opoho...@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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 11:53:26AM +, Tom Hughes via devel wrote:
> On 06/12/2023 11:08, Ondrej Pohorelsky wrote:
> 
> > The only difference is that if you have populated the cron.deny list,
> > after update it gets saved as .rpmsave and cron.allow is created.
> > If the cron.deny is blank, it will get replaced.
> > Also, if you had cron.allow populated before, it will stay this way and
> > blank cron.allow.rpmnew is created.
> 
> Surely there is one more change though?
> 
> Namely that users who could previously run crontab to create
> cron jobs can no longer do so unless they have been added to
> the cron.allow file.
> 
> That seems like a breaking change to me?

Yes, making cron unusable out of the box for non-root users feels like
an pretty major regression in behaviour.

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@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

Re: Change of cronie and crontabs CIS compliance

[Tom Hughes via devel]

On 06/12/2023 11:08, Ondrej Pohorelsky wrote:

The only difference is that if you have populated the cron.deny list, 
after update it gets saved as .rpmsave and cron.allow is created.

If the cron.deny is blank, it will get replaced.
Also, if you had cron.allow populated before, it will stay this way and 
blank cron.allow.rpmnew is created.


Surely there is one more change though?

Namely that users who could previously run crontab to create
cron jobs can no longer do so unless they have been added to
the cron.allow file.

That seems like a breaking change to me?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 12:39 PM Fabio Valentini 
wrote:

> On Wed, Dec 6, 2023 at 11:17 AM 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.
>
> Just out of curiosity - what does CIS even stand for?
> The linked Red Hat docs don't expand the acronym, and googling for it
> obviously yields results for something entirely different
>

Basically, it is a Center for Internet Security (CIS) benchmark that some
companies use as a reference to limit configuration-based security
vulnerabilities.
I'm not really sure, but I think some governments require that their
systems are compliant.

You can look at CIS wikipedia page for more info:
https://en.wikipedia.org/wiki/Center_for_Internet_Security#CIS_Controls_and_CIS_Benchmarks

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Daniel P . Berrangé]

On Wed, Dec 06, 2023 at 12:39:02PM +0100, Fabio Valentini wrote:
> On Wed, Dec 6, 2023 at 11:17 AM 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.
> 
> Just out of curiosity - what does CIS even stand for?
> The linked Red Hat docs don't expand the acronym, and googling for it
> obviously yields results for something entirely different

It'll be referring to

  https://www.cisecurity.org/benchmark/red_hat_linux

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@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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 12:32 PM Michael J Gruber 
wrote:

>
> Thanks, that sounds like the typical things to expect during an upgrade.
> We typically don't even have release notes mentioning this, but it would be
> nice, since it's even a "plus" for F40 (compliance, hardening).
>
> Does that mean making a change proposal? Sorry, I haven't done this before

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Fabio Valentini]

On Wed, Dec 6, 2023 at 11:17 AM 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.

Just out of curiosity - what does CIS even stand for?
The linked Red Hat docs don't expand the acronym, and googling for it
obviously yields results for something entirely different

Fabio
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Michael J Gruber]

Am Mi., 6. Dez. 2023 um 12:09 Uhr schrieb Ondrej Pohorelsky <
opoho...@redhat.com>:

>
>
> On Wed, Dec 6, 2023 at 11:26 AM Michael J Gruber 
> wrote:
>
>> Hi there,
>>
>> what is the impact of these changes:
>> - Do default installs work the same way as before?
>> - Do existing setups (crontabs) keep working?
>>
>> If yes then I'd consider the permission changes to be fixes, or at least
>> standard packaging changes.
>>
>> What is is the policy for existing cron.allow/cron.deny, i.e. what would
>> `rpmconf -a` tell me?
>>
>>
> The default installs work same as before.
> Existing crontabs keep working as usual.
>
> The only difference is that if you have populated the cron.deny list,
> after update it gets saved as .rpmsave and cron.allow is created.
> If the cron.deny is blank, it will get replaced.
> Also, if you had cron.allow populated before, it will stay this way and
> blank cron.allow.rpmnew is created.
>
>
Thanks, that sounds like the typical things to expect during an upgrade. We
typically don't even have release notes mentioning this, but it would be
nice, since it's even a "plus" for F40 (compliance, hardening).

Cheers
Michael
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

On Wed, Dec 6, 2023 at 11:26 AM Michael J Gruber 
wrote:

> Hi there,
>
> what is the impact of these changes:
> - Do default installs work the same way as before?
> - Do existing setups (crontabs) keep working?
>
> If yes then I'd consider the permission changes to be fixes, or at least
> standard packaging changes.
>
> What is is the policy for existing cron.allow/cron.deny, i.e. what would
> `rpmconf -a` tell me?
>
>
The default installs work same as before.
Existing crontabs keep working as usual.

The only difference is that if you have populated the cron.deny list, after
update it gets saved as .rpmsave and cron.allow is created.
If the cron.deny is blank, it will get replaced.
Also, if you had cron.allow populated before, it will stay this way and
blank cron.allow.rpmnew is created.

-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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

Re: Change of cronie and crontabs CIS compliance

[Michael J Gruber]

Am Mi., 6. Dez. 2023 um 11:17 Uhr schrieb Ondrej Pohorelsky <
opoho...@redhat.com>:

> 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.
>
> 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)
> `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)
>
> Reference for these changes:
> static.open-scap.org/ssg-guides/ssg-rhel9-guide-cis.html
>
> PR:
> https://src.fedoraproject.org/rpms/cronie/pull-request/12
> https://src.fedoraproject.org/rpms/crontabs/pull-request/6
>
> Let me know what you think.
> Cheers,
> --
>
Hi there,

what is the impact of these changes:
- Do default installs work the same way as before?
- Do existing setups (crontabs) keep working?

If yes then I'd consider the permission changes to be fixes, or at least
standard packaging changes.

What is is the policy for existing cron.allow/cron.deny, i.e. what would
`rpmconf -a` tell me?

Cheers
Michael
--
___
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

Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

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.

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)
`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)

Reference for these changes:
static.open-scap.org/ssg-guides/ssg-rhel9-guide-cis.html

PR:
https://src.fedoraproject.org/rpms/cronie/pull-request/12
https://src.fedoraproject.org/rpms/crontabs/pull-request/6

Let me know what you think.
Cheers,
-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@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