[SUMMARY] cron.allow, cron.deny: what's the big deal?
Dan_Jacobson at ATT.COM
Dan_Jacobson at ATT.COM
Wed Mar 27 07:45:40 AEST 1991
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 at ATT.COM Naperville IL USA +1 708 979 6364
>>>>> On Sat, 23 Mar 91 21:38:14 CST, fwp1 at 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 at cs.hut.fi> said:
Jyrki> In article <DANJ1.91Mar23195339 at 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 at 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 at ATT.COM Naperville IL USA +1 708 979 6364
More information about the Comp.unix.admin
mailing list