PKGS-7370: debsums cron check does not examine /etc/crontab or /var/spool/cron/crontabs/root

[moerkey]

Describe the bug
The current check for existing cronjobs only examines those delivered with the package. However, I manage my own cronjobs through /etc/crontab, /var/spool/cron/crontabs/root, or /etc/cron.d/. Could be related to #1275.

Version

• Ubuntu 22.04
• Lynis version 3.1.2-100

Expected behavior
I suggest that the check be updated to include these custom cronjob files for a more comprehensive assessment.

Output

2024-10-10 20:13:21 Performing test ID PKGS-7370 (Checking for debsums utility)
2024-10-10 20:13:21 Result: debsums utility is installed
2024-10-10 20:13:21 Hardening: assigned maximum number of hardening points for this item (1). Currently having 107 points (out of 124)
2024-10-10 20:13:21 Result: Cron job is not configured for debsums utility.
2024-10-10 20:13:21 Hardening: assigned partial number of hardening points (1 of 3). Currently having 108 points (out of 127)
2024-10-10 20:13:21 Suggestion: Check debsums configuration and enable checking regularly via a cron job (CRON_CHECK in default file). [test:P
KGS-7370] [details:-] [solution:-]

Additional context
Thank you for your work on Lynis!

[jpasher-lazor]

I think when you start straying from the package-maintained defaults, you're getting into special, one-off use cases that general utilities like Lynis won't be able to detect.

Right now, the cron job check looks for a file called debsums (the package installs /etc/cron.{daily,monthly,weekly}/debsums by default). This file is more than just a one line command that would be run from /etc/crontab or /var/spool/cron/crontabs/root. How exactly are you running debsums from those files? Are you calling some other script? What would you expect Lynis to look for that is not a custom hack specific to your use case?

Incidentally, managing cron jobs in /etc/crontab is a little bizarre. You should normally leave that file as stock and use /etc/cron.d for your custom cron jobs.

[moerkey]

I think when you start straying from the package-maintained defaults, you're getting into special, one-off use cases that general utilities like Lynis won't be able to detect.

I can understand your point and challenge, but I want to execute debsums to a specific time.

Right now, the cron job check looks for a file called debsums (the package installs /etc/cron.{daily,monthly,weekly}/debsums by default). This file is more than just a one line command that would be run from /etc/crontab or /var/spool/cron/crontabs/root. How exactly are you running debsums from those files? Are you calling some other script? What would you expect Lynis to look for that is not a custom hack specific to your use case?

All these files, which Lynis is looking for, do exist.

find /etc/ -type f -name debsums
/etc/cron.monthly/debsums
/etc/default/debsums
/etc/cron.daily/debsums
/etc/cron.weekly/debsums

But I disabled them via /etc/default/debsums.

# Defaults for debsums cron jobs
# sourced by /etc/cron.d/debsums

#
# This is a POSIX shell fragment
#

# Set this to never to disable the checksum verification or
# one of "daily", "weekly", "monthly" to enable it
CRON_CHECK=never

As I mentioned above. I want to control the exact timing of when debsums is executed. This can be configured in /var/spool/cron/crontabs/*, /etc/crontab, or /etc/cron.{daily,monthly,weekly}/. It might be useful to respect the never flag and then use grep on these paths while ensuring that debsums is not commented out.

I believe this could get just one example of many, especially if Lynis cross-checks the execution of such tools. In light of this, I’d suggest re-evaluating your strategy.

Incidentally, managing cron jobs in /etc/crontab is a little bizarre. You should normally leave that file as stock and use /etc/cron.d for your custom cron jobs.

Is that your personal opinion, or is it an official recommendation? I will consider your suggestion. But in that case, your check could use a grep over these well known cron paths. Or is there a recommendation for a filename under these path which will be considered by Lynis.

[jpasher-lazor]

I can understand your point and challenge, but I want to execute debsums to a specific time.

Fair enough, but you have to remember that with each customization, your system becomes unique from everyone else, which makes accurate detection that much harder.

All these files, which Lynis is looking for, do exist.
...
But I disabled them via /etc/default/debsums.
...

CRON_CHECK=never

That is what is tripping up Lynis. It explicitly looks for a value of "daily", "weekly", or "monthly", since that is the standard way of enabling the debsums cron job. Specifying "never" disables it, as far as Lynis can detect.

As I mentioned above. I want to control the exact timing of when debsums is executed. This can be configured in /var/spool/cron/crontabs/*, /etc/crontab, or /etc/cron.{daily,monthly,weekly}/. It might be useful to respect the never flag and then use grep on these paths while ensuring that debsums is not commented out.

I am guessing this means you are making a call to the /etc/cron.{daily,monthly,weekly}/debsums script from one of your custom cron tab files (/etc/crontab or /var/spool/cron/crontabs/*)? I guess one way would be to grep the files at /etc/crontab, /etc/cron.d/*, and /var/spool/cron/crontabs/* for an uncommented line that run the normal debsums cron job script. For accuracy, it might need to perform a stricter check on the command instead of a simple partial match. It would have to treat /var/spool/cron/crontabs/* differently, since it doesn't have a column for the username.

What do your custom cron job calls look like in those files?

Incidentally, managing cron jobs in /etc/crontab is a little bizarre. You should normally leave that file as stock and use /etc/cron.d for your custom cron jobs.

Is that your personal opinion, or is it an official recommendation? I will consider your suggestion. But in that case, your check could use a grep over these well known cron paths. Or is there a recommendation for a filename under these path which will be considered by Lynis.

Whether there is an official recommendation or not, I don't know, but the general rule of thumb is that for services that support the .d-style config snippets, you create your snippets in that .d directory and avoid changing the package-provided file. That will help reduce conflicts if you upgrade the package and upstream has made changes that conflict with your changes. The exception would be when you cannot override a setting with a config snippet. In the case of /etc/crontab, if you want to change the exact time used for daily, weekly, and monthly jobs, then you have no choice but to change the file.

I also personally avoid cron jobs tied to specific user's crontab (even the root user) for server-level functionality like this. The file at /var/spool/cron/crontabs/root could just be placed in /etc/cron.d and run the same way (the only difference being an additional column before the command to specify the user). This makes it a lot easier to see what cron jobs are running on the server, instead of having to check multiple places.

Just to clarify, I'm not a maintainer for Lynis. I am just a regular user that has made a small contribution or two.

[moerkey]

I can understand your point and challenge, but I want to execute debsums to a specific time.

Fair enough, but you have to remember that with each customization, your system becomes unique from everyone else, which makes accurate detection that much harder.

All these files, which Lynis is looking for, do exist.
...
But I disabled them via /etc/default/debsums.
...

CRON_CHECK=never

That is what is tripping up Lynis. It explicitly looks for a value of "daily", "weekly", or "monthly", since that is the standard way of enabling the debsums cron job. Specifying "never" disables it, as far as Lynis can detect.

As I mentioned above. I want to control the exact timing of when debsums is executed. This can be configured in /var/spool/cron/crontabs/*, /etc/crontab, or /etc/cron.{daily,monthly,weekly}/. It might be useful to respect the never flag and then use grep on these paths while ensuring that debsums is not commented out.

I am guessing this means you are making a call to the /etc/cron.{daily,monthly,weekly}/debsums script from one of your custom cron tab files (/etc/crontab or /var/spool/cron/crontabs/*)? I guess one way would be to grep the files at /etc/crontab, /etc/cron.d/*, and /var/spool/cron/crontabs/* for an uncommented line that run the normal debsums cron job script. For accuracy, it might need to perform a stricter check on the command instead of a simple partial match. It would have to treat /var/spool/cron/crontabs/* differently, since it doesn't have a column for the username.

What do your custom cron job calls look like in those files?

Incidentally, managing cron jobs in /etc/crontab is a little bizarre. You should normally leave that file as stock and use /etc/cron.d for your custom cron jobs.

Is that your personal opinion, or is it an official recommendation? I will consider your suggestion. But in that case, your check could use a grep over these well known cron paths. Or is there a recommendation for a filename under these path which will be considered by Lynis.

Whether there is an official recommendation or not, I don't know, but the general rule of thumb is that for services that support the .d-style config snippets, you create your snippets in that .d directory and avoid changing the package-provided file. That will help reduce conflicts if you upgrade the package and upstream has made changes that conflict with your changes. The exception would be when you cannot override a setting with a config snippet. In the case of /etc/crontab, if you want to change the exact time used for daily, weekly, and monthly jobs, then you have no choice but to change the file.

I agree, but the timing of cron jobs should not be decided by the package maintainer. The execution times for jobs under /etc/cron.{daily,monthly,weekly}/, which are defined in /etc/crontab should not be globally fixed by the package. Users should have the flexibility to configure these schedules as needed.

I also personally avoid cron jobs tied to specific user's crontab (even the root user) for server-level functionality like this. The file at /var/spool/cron/crontabs/root could just be placed in /etc/cron.d and run the same way (the only difference being an additional column before the command to specify the user). This makes it a lot easier to see what cron jobs are running on the server, instead of having to check multiple places.

Yes, if it's feasible to manage everything independently. However, on a multi-user system, users would be constrained by the permissions set for the cron directories in /etc, or by the decisions of the root administrator.

Just to clarify, I'm not a maintainer for Lynis. I am just a regular user that has made a small contribution or two.

Thank you for the clarification. In that case, I would suggest a Lynis maintainer weigh in on this topic, as otherwise, it could turn into unnecessary detail.

I keep my simple suggestion: On Ubuntu 24.04, please grep through /etc/crontab, /etc/cron.d, and /var/spool/cron/crontabs/root for the execution of debsums when /etc/default/debsums is set to CRON_CHECK=never.

Background: System administrators often need to adjust cron job schedules to balance server load, backups, or security scans, especially in a server farm. This can be done by modifying /etc/crontab as needed. Lynis shouldn't enforce the package's default timing for running debsums. If someone is managing debsums, they likely understand the implications and should have the flexibility to adjust the system according to their needs, regardless of whether or not they modify basic system files.