[/usr/bin/at] Security implications and inhibiting mail reports

[fonz]

While pondering whether I could use at(1) for something I'm toying with I started wondering about two things:

• By default only root may use at. Does allowing mortal users to use at raise any significant security issues? The jobs are executed with the UID of the issuer and while users can see that some other user has some job scheduled, they can't see what or when.
• As far as I can tell, it appears impossible (without hacking the source that is) to let at execute jobs but not send e-mails with the results/output. Is that right?

Any input is welcome.

 

[ShelLuser]

Cool stuff!

Just finished work (yes, some people work until 1am) while peeking in here every now and then during work but this is just what I like when I can finally relax and enjoy a cold beer

Although my experience in this stems mostly from Linux I obviously did look up some of the things on FreeBSD as well. However; keep this in mind as I can't claim to be 100% sure about everything I share here.

[*]By default only root may use at. Does allowing mortal users to use at raise any significant security issues?

It does raise some security issues and I think they can be significant. The reason I feel that security is involved is because of this:

chihiro:/home/peter $ ls -l `which at` `which crontab`
-r-sr-xr-x  4 root  wheel  29656 Dec  4  2012 /usr/bin/at
-r-sr-xr-x  1 root  wheel  32840 Dec  4  2012 /usr/bin/crontab

As you can see at (as well as crontab) have the setuid bit set, that makes them both a security issue to me, even though it might be minimal (executables which have the setuid bit set always do that to me).

Yet the other reason why I feel this way is because at actually seems to be fully controlled by crontab. Check this out:

chihiro:/home/peter $ grep atrun /etc/crontab
*/5     *       *       *       *       root    /usr/libexec/atrun

This behaviour is also confirmed in the at(1) manual page as well as the atrun(8) manual page. Because there's always a "5 minute window" this doesn't make at the best tool to carefully time something. But I also wonder if that time overhead couldn't also decrease the risks: you can basically tell crontab to execute something the very next (same?) minute whereas this isn't so obvious with at.

Even so, there's something else to worry about...

[*]As far as I can tell, it appears impossible (without hacking the source that is) to let at execute jobs but not send e-mails with the results/output. Is that right?

Ok, so this is one of those issues I'm not 100% sure about but I'm going to share my idea anyway. I think you're right, but I also think you might be overlooking another obvious problem: generating output also means assuming that the job at hand actually generated output in the first place. As you know it's pretty easy to send that to /dev/null.

Which is in my opinion one of the reasons at is less secure then cron. When a job is executed through crontab you see something like this:

Jun  9 13:35:00 smtp2 /usr/sbin/cron[79844]: (root) CMD (/usr/libexec/atrun)
([I]root ran atrun[/I])
Jun  9 15:00:00 smtp2 /usr/sbin/cron[82377]: (root) CMD (newsyslog)
([I]root ran newsyslog[/I])
Jun  9 22:40:00 smtp2 /usr/sbin/cron[32571]: (root) CMD (/usr/local/etc/webmin/virtualmin-awstats/awstats.pl synthfan.info)
([I]root updated stats for my synthesizer hobby site[/I])

Although I only picked out jobs executed by root the exact same thing applies to jobs scheduled by a common user: you see exactly what has been scheduled and what is being executed.

So what do you get to see when atrun does something? You see in the /var/log/cron that it was executed with root privileges, but what more can you tell about it? Especially when there's no output generated by the scheduled command?

I think that's what makes at more of a risk factor in comparison to crontab.

 

[fonz]

As you can see at (as well as crontab) have the setuid bit set

Should have spotted that myself, really :r For me personally it's not a big deal, but for an application that might be used by others I find it undesirable.

Yet the other reason why I feel this way is because at actually seems to be fully controlled by crontab.
[snip]
Because there's always a "5 minute window" this doesn't make at the best tool to carefully time something.

That I did know and it's something I can live with.

generating output also means assuming that the job at hand actually generated output in the first place.

Good call. In my particular case, there might not always be any output.

When a job is executed through crontab you see something like this:
[snip]
Although I only picked out jobs executed by root the exact same thing applies to jobs scheduled by a common user: you see exactly what has been scheduled and what is being executed.

Agreed. However, the jobs are usually short and scheduled at irregular intervals, so that I could probably live with.

All things considered, I think that at isn't the right tool for what I want. And as a bonus, I've been made aware of a few things to keep in mind when using at in general, thanks for that.

 

[ta0kira]

Of interest to me would be whether or not atrun sets the user's login class and MAC label. My guess is that the former might be set (50/50) and that the latter isn't set. Failing to set the login class is only of consequence if rctl is used, which could result in a user using up the resource limits of the login class that cron, etc. run under. Failing to set the MAC label has fairly obvious consequences, but that's only a problem if you use MAC. Now that I'm thinking about it, I'll have to check cron regarding the MAC label.

edit: It looks like both cron and atrun set the login class, MAC label, and resource limits (look for setusercontext in the source code for each.) Good to know!

Kevin Barry