Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 607426 - sys-process/cronbase: wrong permissions on dirs lets any user to use cron.
Summary: sys-process/cronbase: wrong permissions on dirs lets any user to use cron.
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security Audit Team
URL:
Whiteboard:
Keywords:
: 605816 607430 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-01-27 21:11 UTC by Piotr Karbowski
Modified: 2019-03-29 13:04 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2017-01-27 21:11:27 UTC
cronbase that installs /var/spool/cron sets up the wrong permissions there. Although ebuild seems to attempt to make it root:cron 750, the directory /var/spool/cron (and /etc/cron.*) is installed as cron:root 755, which allows any system user to setup crontabs, regardless of the cron group membership. On a gentoo system installed two years ago, the permissions are root:cron 750.

    diropts -m0750
    keepdir /etc/cron.{hourly,daily,weekly,monthly}

    keepdir /var/spool/cron/lastrun
    diropts -m0750 -o root -g cron
    keepdir /var/spool/cron

Maybe the diropts does not works as ebuild author intended, or maybe there is a bug in portage. Nonetheless, I'd consider it as a major security issue.

sys-apps/portage-2.3.3
sys-process/cronbase-0.3.7-r6
Comment 1 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2017-01-27 21:20:42 UTC
So, it seems that if the dirs exist (because for example, vixie-cron was installed before, or anything has been added into /etc/cron.daily, the keedir of cronbase will not adjust permissions. Meaning if one emerges other packages prior to cronbase, the system is vulnerable.
Comment 2 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2017-01-27 21:42:12 UTC
as portage does not copy permissions on dirs from $D during merging to rootfs (which seems resonable) shouldn't everything that installs anything in /var/spool/cron and /etc/cron.* depends on cronbase, to make sure it is installed (and permissions are set) prior to installing own files there?
Comment 3 Zac Medico gentoo-dev 2017-01-27 21:51:09 UTC
The directory permissions come from the first package to install the directory, due to bug 141619.
Comment 4 Mike Gilbert gentoo-dev 2017-01-28 05:04:34 UTC
*** Bug 605816 has been marked as a duplicate of this bug. ***
Comment 5 Kristian Fiskerstrand (RETIRED) gentoo-dev 2017-01-28 12:25:48 UTC
*** Bug 607430 has been marked as a duplicate of this bug. ***
Comment 6 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2017-01-28 19:15:07 UTC
I do not think a status unconfirmed is right one.

Anyhow. I've found what does make the /var/spool/cron be cron:root 755.

When merging cronbase for the first time the cron user is created with home set to /var/spool/cron.


>>> Emerging (1 of 1) sys-process/cronbase-0.3.7-r6::gentoo
openpty failed: 'out of pty devices'
 * Adding group 'cron' to your system ...
 *  - Groupid: 16
 * Adding user 'cron' to your system ...
 *  - Userid: 16
 *  - Shell: /sbin/nologin
 *  - Home: /var/spool/cron
 *  - Groups: cron
 *  - GECOS: added by portage for cronbase
 *  - Creating /var/spool/cron in /

And then the ebuild have the keepdir with right right permissions, but since the /var/spool/cron will exist before it gets to the keepdir, nothing is really applied.
Comment 7 Zac Medico gentoo-dev 2017-01-29 19:31:12 UTC
In cronbase-0.3.3.ebuild we had chown/chmod in pkg_postinst, which we don't have in later versions:

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/cronbase/cronbase-0.3.3.ebuild?id=ca727c9567a7ac4023ade8cce10e26a6376c2cae
Comment 8 Zac Medico gentoo-dev 2017-01-29 19:38:51 UTC
The pkg_postinst was dropped by vapier in the version bump to 0.3.4:

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-process/cronbase/cronbase-0.3.4.ebuild?revision=1.1&view=markup
Comment 9 Ian Zimmerman 2018-01-11 21:10:20 UTC
I think I understand the problem with /var/spool/cron being 755.

But I have a much harder time with /etc/cron.*.  Can someone explain what problem is solved by setting them to 750?  Other than the cronjobs there just being readable by everyone - which is a good thing, IMO, just like a world readable /etc/passwd is.  If there is an exceptionally badly written job that contains secret info one can always just set the job itself to mode 700, or not?