Dan_Jacobson@ATT.COM (03/27/91)
OK, thanks folks... here's my summary, from e-mail. Please post any further replies. In general users could tie up the system from dumb crontab entries just as well as from dumbness at the interactive shell command line. Dan_Jacobson@ATT.COM Naperville IL USA +1 708 979 6364 >>>>> On Sat, 23 Mar 91 21:38:14 CST, fwp1@CC.MsState.Edu (Frank Peters) said: Frank> A sample crontab entry: Frank> * * * * * some-heavy-program Frank> A few of these can bring a system to its knees real quickly. Frank> Admittedly not usually a problem (which is why cron and at security Frank> are effectively off by default) but I do know of at least one site Frank> that had problems with a malicious user doing this. Frank> More generally, cron and at allow users to use system resources even Frank> when they aren't on the system. I can see some strange situations Frank> where you might not want users to have that ability on a more secure Frank> system. Frank> Frank >>>>> On Sun, 24 Mar 91 16:07:31 +0200, Jyrki Kuoppala <jkp@cs.hut.fi> said: Jyrki> In article <DANJ1.91Mar23195339@cbnewse.ATT.COM> you write: >So what's the big security increase gained by having to ask root to >let you use crontab? The only cron related problem I can see is >forgetting to remove a user's crontab and at(1) jobs when her/his >account is deleted, e.g., at the end of the semester. Am I just dim? Jyrki> In the past, there have been some problems with at/cron allowing users Jyrki> to do things they aren't supposed to (like submitting cron or at jobs Jyrki> for the user root or looking at any file from crontab error messages). Jyrki> On modern Unix versions it seems that many of these problems have been Jyrki> corrected. Jyrki> The reason cron.allow and cron.deny exist is probably unrelated to the Jyrki> bugs - I suppose it's just provided to the system administrators as a Jyrki> convenienve so they can have better control over what the users do on Jyrki> the system if they for some reason want it. Like all those myriads of Jyrki> security bits in the Vomit Making System or somesuch to allow Jyrki> administrators to set the permissions separately for the things a user Jyrki> is allowed to do. Jyrki> //Jyrki >>>>> On Mon, 25 Mar 91 16:38 CST, gordon@sneaky.lonestar.org (Gordon Burditt) said: >So what's the big security increase gained by having to ask root to >let you use crontab? The only cron related problem I can see is >forgetting to remove a user's crontab and at(1) jobs when her/his >account is deleted, e.g., at the end of the semester. Am I just dim? Gordon> In one instance I saw a gross abuse of crontab that was solved by Gordon> having the administrator talk to the user rather than with cron.allow Gordon> and cron.deny. The user set up some background jobs to detect whether Gordon> his files were being modified or accessed while he wasn't logged in, Gordon> to delete old listing files in his tree over a certain age, and Gordon> to do a "make" in certain directories to bring them up to date. He Gordon> was also working on a scan-the-whole-system security checking program. Gordon> The trouble was, he was firing off all these things *EVERY Gordon> MINUTE*. The jobs took several minutes to complete, bringing Gordon> the load to new highs, and causing several complaints about Gordon> problems with cross-compilers generating bad object files Gordon> caused by multiple compilations of the same file at the same Gordon> time. One of his scripts was accidentally infinitely Gordon> recursive. It didn't hog all of the system process slots, but Gordon> it was still annoying. Other users complained that their Gordon> overnight jobs didn't always finish overnight. Gordon> The administrators talked him into doing most of the jobs once a night, Gordon> and a few once an hour. Gordon> Gordon L. Burditt Gordon> sneaky.lonestar.org!gordon [by the way, also it is good to check no users being removed from a machine have any mail loop causing stuff... -Dan J.] -- Dan_Jacobson@ATT.COM Naperville IL USA +1 708 979 6364