On 27/03/14 10:01 PM, Gaetan Bisson wrote:
[2014-03-27 21:01:17 -0400] Daniel Micay:
setuid binary (crontab) so it opens up a vulnerability in the base install.
Among others (although one requires cron to be enabled):
* https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097
There were bugs that have been fixed a while ago; what's your point?
My point was only that the security risk is not theoretical. The only other arguments I have against including packages in base are disk and bandwidth usage and I don't think those are important when we're talking about such small numbers. Reducing the attack surface of most Arch installs is a stronger reason to keep base small. I think cutting down the number of setuid binaries shipped in base (and overall) would be great, and crontab is one of the few that we can't eventually switch to a significantly less scary capability like CAP_NET_RAW.
I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place.
Removing a daemon that's not enabled by default would help to streamline the base install too.
But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue.
I don't think systemd timers allow non-root users to run timer units outside of their session and the systemd session binary runs as non-root. AFAIK avoiding setuid binaries is one of the reasons for tools like hostnamectl using a client-server model.