Does the use of cron (HP-UX 11) present a security risk IF it is only given to accounts which have shell access anyway.
If it does present a risk, what is the risk?
Can a script (or command) run via cron; run anything, write anywhere or read anywhere that the same user can not do outside of cron?
The risk is only for restricted or chrooted accounts being able to access files the account could never access before.
The risk is the same for a user with shell access, and the same user with access to commands/files via crontab. Ditto at and batch.
For any valid shell user, accessing crontab has a greater chance of screwing things up, because the environment in cron jobs is not the same as the interactive environment. This leads to errors and bad code trashing things.
So if security is set correctly, inept crontab users mostly trash their own stuff.
So, how do you want to define security?
We never allow users permissions for cron. This is a quality control and scheduling decision and not a security issue as such. We use "su" from the root cron to execute scripts in the name of the user and have automated scripts to check the cron log and the root mail file for errors.
There was a thread on unix.com recently where a badly-written user cron executed a command which hung. After a while the cron queue limit was exceeded and the system crons stopped running.
I had a trusted contractor who had access to run "at" jobs but not to run "cron" jobs. After he left a process stopped working after a reboot. It turned out (after a lot of detective work) that he was using self-spawning "at" jobs to stop/start the background processes. Ever since then all automated start/stop scripts have been tested from cron at the same time that the code is tested.