dcron & crontab permission

Thom1b · 01-15-2024, 09:17 AM

Hi,

It seems I want to change many things in dcron

If too few people think it's useful, I'll forget my following suggestion.

I read this in the crontab manpage:

Quote:

Only users who belong to the same group as the crontab binary will be able to install or edit crontabs. However it’ll be possible for the superuser to install crontabs even for users who don’t have the privileges to install them themselves. (Even for users who don’t have a login shell.) Only the superuser may use the ‐u or ‐c switches to specify a different user and/or crontab directory.

I understand crontab command should be run by a trusted user only. This is not the case in Slackware, crontab can be run by any user.

Even the dcron github homepage says by default crontab permissions allow only root and users in wheel group to run it:

Quote:

INSTALLING
----------

(4) `make install` installs the files underneath PREFIX (by default, /usr/local).
If you're packaging, you can supply a DESTDIR argument here:

make DESTDIR=/path/to/your/package/root install

Permissions will be as follows:

-rwx------ 0 root root 32232 Jan 6 18:58 /usr/local/sbin/crond
-rwsr-x--- 0 root wheel 15288 Jan 6 18:58 /usr/local/bin/crontab

Only users belonging to crontab's group (here "wheel") will be able to use it.
You may want to create a special "cron" group and assign crontab to it:

groupadd cron
chgrp cron /usr/local/bin/crontab
chmod 4750 /usr/local/bin/crontab

(If the group already exists, you can specify it by supplying CRONTAB_GROUP
to the `make` or `make install` commands.)

If you think crontab should be run only by trusted users, I suggest this little patch in dcron SB:

Code:

*** dcron.SlackBuild	2024-01-15 16:07:50.560059014 +0100
--- dcron.SlackBuild.new	2024-01-15 16:08:58.591341660 +0100
***************
*** 96,102 ****
    BINDIR=/usr/bin \
    SBINDIR=/usr/sbin \
    MANDIR=/usr/man \
!   CRONTAB_GROUP=root \
    || exit 1
  
  # This works now, but predictability is a good thing...
--- 96,102 ----
    BINDIR=/usr/bin \
    SBINDIR=/usr/sbin \
    MANDIR=/usr/man \
!   CRONTAB_GROUP=wheel \
    || exit 1
  
  # This works now, but predictability is a good thing...
***************
*** 110,116 ****
  
  mkdir -p $PKG/usr/bin
  cat crontab > $PKG/usr/bin/crontab
! chmod 4711 $PKG/usr/bin/crontab
  
  # Add run-parts script and man page, largely taken from Fedora:
  zcat $CWD/run-parts.gz > $PKG/usr/bin/run-parts
--- 110,117 ----
  
  mkdir -p $PKG/usr/bin
  cat crontab > $PKG/usr/bin/crontab
! chown root:wheel $PKG/usr/bin/crontab
! chmod 4710 $PKG/usr/bin/crontab
  
  # Add run-parts script and man page, largely taken from Fedora:
  zcat $CWD/run-parts.gz > $PKG/usr/bin/run-parts

Petri Kaukasoina · 01-15-2024, 09:35 AM

Quote:

Originally Posted by Thom1b

I understand crontab command should be run by a trusted user only.

Why? There is nothing privileged to run cron jobs. The cron jobs run using the user's own uid.

Quote:

allow only root and users in wheel group to run it

I give wheel group rights to become root in /etc/sudoers. And the default /etc/cups/cups-files.conf lets wheel administer printers.

Thom1b · 01-15-2024, 10:14 AM

Quote:

Originally Posted by Petri Kaukasoina

Why? There is nothing privileged to run cron jobs. The cron jobs run using the user's own uid.

As I said, it's just a suggestion we can forget quickly, I don't think it's a security issue.
Manpage says crontab command should be run only by trusted users (and is the vanilla behaviour) but this is not the case so manpage is wrong, that's why I suggest this change. But we can change manpage to be true with current behaviour.
run-parts can be run by any user, so if crontab must be run only by root or wheel users, anyone can still add/modify its own jobs in its own cron directory without special permission.

lostintime · 01-15-2024, 12:11 PM

Quote:

I understand crontab command should be run by a trusted user only. This is not the case in Slackware, crontab can be run by any user.

The man page does seem confusing with actual behavior.

I think part of the reason is in the build script, setuid (chmod 0411) is used to change the behavior of /usr/bin/crontab.

Perhaps rather than patching the source code, the man page could be updated?

AS IS
=====

Only users who belong to the same group as the crontab binary will be able to install or edit crontabs.

CHANGE TO
=========

Unless modified with setuid, only users who belong to the same group as the crontab binary will be able to install or edit crontabs.

henca · 01-15-2024, 12:36 PM

I agree with those who think that it is useful (and sometimes safer) to run cron jobs as a normal user.

Yes, the crontab binary is setuid root, and any security hole in that binary might give a privilege escalation, but still, the usefullness of being able to run cron jobs as a normal user should be weighted against placing more or less secure cron jobs in privileged accounts.

The reason that the crontab binary is setuid root is that /var/spool/cron is only accessible by privileged users and below that directorie lives all users crontabs.

regards Henrik

Thom1b · 01-15-2024, 11:37 PM

Let's go with a fixed manpage

Thanks for your answers!

GazL · 01-16-2024, 03:32 AM

If you're going to allow users to edit their own crontab files then the suid bit is unavoidable given how dcron currently operates.

The man-page is fine. It does exactly what it says on the tin.
The problem is that on slackware /usr/bin/crontab has o=--x

Using 'users' for CRONTAB_GROUP seems the most sensible approach to me. Giving:
-rwsr-x--- 1 root users 18896 Sep 27 23:42 /usr/bin/crontab

(that's how i built it for my crux system)

Petri Kaukasoina · 01-16-2024, 04:12 AM

Quote:

Originally Posted by GazL

-rwsr-x--- 1 root users 18896 Sep 27 23:42 /usr/bin/crontab

I prefer the way it is now. Your change means crontab users should be added to group 'users'. There are other conventions, for example in my work Slackware and other work accounts, my primary group is different, and I am not in group 'users'. If a special group for allowing crontab is wanted, maybe a supplementary group of 'crontab' would be used, instead of overloading 'wheel' or 'users' for that.

GazL · 01-16-2024, 04:19 AM

Even when my user has it's own primary group, I still put it in 'users', but yes, it's all preference. The problem with the current scheme is that 'nobody' could run /usr/bin/crontab which while not terrible, is not ideal.

Thom1b · 01-16-2024, 04:30 AM

Quote:

Originally Posted by Petri Kaukasoina

If a special group for allowing crontab is wanted, maybe a supplementary group of 'crontab' would be used, instead of overloading 'wheel' or 'users' for that.

Sounds great!

marav · 01-16-2024, 05:49 AM

Here it doesn't change anything
No matter what you put in CRONTAB_GROUP, all users are allowed to create crontab

With the default CRONTAB_GROUP=root

Code:

blackstar:~:# grep test /etc/group
test:x:1002:
blackstar:~:# crontab -u test -l  
*/1 * * * * wall Hello
blackstar:~:#

Code:

Broadcast message from test@blackstar.local (somewhere) (Tue Jan 16 12:48:01 20
                                                                               
Hello

Petri Kaukasoina · 01-16-2024, 05:59 AM

There remains the question why crontab should be allowed only for some.

1) One reason could be that it is suid root and that's why it could be a security risk. But there are lots of other suid root binaries. 'find / -xdev -perm -4000 -user root -ls' lists 40 of them here and /usr/bin/fdmount and /usr/libexec/dbus-daemon-launch-helper are the only ones executable by a special group and not by everyone. For example /usr/libexec/Xorg is a large program, suid root and executable by anyone.

2) Or maybe crontab should be restricted so that wrong people couldn't run processes while not logged in. But then there is 'at' and 'screen' and so on.

GazL · 01-16-2024, 06:57 AM

'at' has /etc/at.allow and /etc/at.deny to control who can use it. dcron simply uses execute permissions of the suid /usr/bin/crontab to control who gets to use it, so there's a different control mechanism at play here. You're right though, there are many ways to get up to mischief, but that doesn't mean one shouldn't pick the low hanging fruit.

The way I look at it 'cron' is a facility for 'normal' users and non-user logonids should not be able to modify their own crontab files (it doesn't mean they can't have them, just that root will have to maintain them), but that's a matter of philosophy/opinion and YMMV. I'm a firm believer in the principle of least privilege.

Whether control is granted via a dedicated group or not I guess depends on how fine grained you want to control its access. For me, the 'users' group seemed like a sensible choice given my outlook, stated above, and had the advantage of not requiring a new group to be added.

GazL · 01-16-2024, 07:00 AM

Quote:

Originally Posted by marav

Here it doesn't change anything
No matter what you put in CRONTAB_GROUP, all users are allowed to create crontab

With the default CRONTAB_GROUP=root

Code:

blackstar:~:# grep test /etc/group
test:x:1002:
blackstar:~:# crontab -u test -l  
*/1 * * * * wall Hello
blackstar:~:#

Code:

Broadcast message from test@blackstar.local (somewhere) (Tue Jan 16 12:48:01 20
                                                                               
Hello

Unless you remove the execute permissions for 'others' it won't matter what group the crontab executable is in.

marav · 01-16-2024, 12:52 PM

Quote:

Originally Posted by GazL

Unless you remove the execute permissions for 'others' it won't matter what group the crontab executable is in.

Yep
And we're back to the first post ;-)