On 28/03/14 10:05, Andrea Scarpino wrote:

On Fri 28, March 01:01:22 Thomas Bächler wrote:

...

Since systemd 212, systemd timers support the Persistent=true option for OnCalendar timers. This is functionality similar to anacron:

Cool!

...

I'd be willing to convert all the core packages and put them to testing if people agree that this is the right course.

+1 from me

Agreed. +1

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.

On 27/03/14 11:26 PM, Gaetan Bisson wrote:

...

My point was only that the security risk is not theoretical.

Of course it isn't: we all know every piece of software has bugs, which is a potential security issue when run as root. Now the above cronie bugs were fixed long ago. Do you have any evidence suggesting systemd should be less bug-prone than cronie?

Arch Linux is going to be shipping systemd in base, whether or not cronie is included. Including more setuid binaries increases the attack surface. I do think it can be assumed that including cronie (with the crontab setuid binary) and systemd will be more prone to exploitation than systemd alone. The importance of this is open to debate, but I think it's worth consideration, especially since cronie is not enabled by default. Perfect security is an unobtainable goal but we can do what we can to harden the base install. It means cron users will need to issue another pacman command, similar to how Arch leaving ptrace_scope enabled by default requires users of commands like `strace -p $PID`, `perf trace -p $PID`, `gdb -p $PID` or `reptyr $PID` to either turn it off or work around it. They're very minor inconveniences for a subset of Arch users and the security benefit is real, even if it's small.

On 28/03/14 06:01 PM, Tom Gundersen wrote:

On Fri, Mar 28, 2014 at 3:01 AM, 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?

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. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue.

I agree with Gaetan that I don't see the big security concern here.

However, I'm always in favor of dropping stuff from base whenever the opportunity arises. Once other base packages no longer ship cron jobs, I suppose there is no longer a reason to keep cronie in base? What's your take on that Gaetan (not sure if your comment was against dropping it, or just against the security concern)?

Cheers,

Tom

It's a very minor security concern, but I think it's a valid reason for having people who want it install it explicitly. It's not currently enabled by default, and will have a narrow use case when the existing packaged cron jobs on are. I don't think there will be a use case for a single user system anymore, or even *most* multi-user ones.

[2014-03-28 23:01:22 +0100] Tom Gundersen:

However, I'm always in favor of dropping stuff from base whenever the opportunity arises. Once other base packages no longer ship cron jobs, I suppose there is no longer a reason to keep cronie in base? What's your take on that Gaetan (not sure if your comment was against dropping it, or just against the security concern)?

Yes, I will be very happy to move cronie out of [core] and stop maintaining it. :) My disagreement was only with the security argument. Cheers. -- Gaetan

Am 29.03.2014 01:31, schrieb Gerardo Exequiel Pozzi:

I guess for man-db should be better use tmpfiles instead of mkdir in the service unit.

The old cron.d script had the mkdir call inside with a comment that the directory should be recreated in case of deletion. I guess having it inside the service makes sure the service works even if someone rm -r's the directory at runtime. IMO mkdir should not be necessary at all, man-db should create the directory itself when needed.

Am 28.03.2014 22:26, schrieb Thomas Bächler:

Am 28.03.2014 01:01, schrieb Thomas Bächler:

...

core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats

After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.

I am not sure how this interacts with suspend. My laptop was suspended at midnight, and on resume two of my timers fired, but 3 didn't. Maybe this is because interaction with suspend is broken, mabe because of AccuracySec set to 12h. I need to investigate this issue further.

Am 01.04.2014 16:44, schrieb Thomas Bächler:

Am 29.03.2014 08:52, schrieb Thomas Bächler:

...

Am 28.03.2014 22:26, schrieb Thomas Bächler:

...

Am 28.03.2014 01:01, schrieb Thomas Bächler:

...

core/logrotate 3.8.7-1 /etc/cron.daily/logrotate core/man-db 2.6.6-1 /etc/cron.daily/man-db core/mlocate 0.26-1 /etc/cron.daily/updatedb core/shadow 4.1.5.1-7 /etc/cron.daily/shadow extra/pkgstats 2.3-3 /etc/cron.weekly/pkgstats

After the overall positive response, I converted these. Since none of my machines used any cron jobs, I uninstalled cronie from them.

I am not sure how this interacts with suspend. My laptop was suspended at midnight, and on resume two of my timers fired, but 3 didn't. Maybe this is because interaction with suspend is broken, mabe because of AccuracySec set to 12h. I need to investigate this issue further.

*shrugs* Seems to work just fine now. All timers fired when I resumed at work today.

Okay, this should stay in testing for the moment. There's a case where the persistent timer *never* run until your machine is running just at the right moment. I prepared a patch for this problem, just need to test and submit it tonight. I also forgot to set the PACKAGER variable on this machine, so the packages have "Unkown packager", I should probably rebuild the packages soon, then.