topic Re: cron - security in Operating System - HP-UX

cron - security

Tom Dawson — Mon, 31 Mar 2003 12:46:11 GMT

All,

I've noticed that in the AusCERT "UNIX Security Checklist v2.0", they recommend that I "CONSIDER disallowing cron for regular users".

I'm inclined to do this for scheduling/performance reasons. But can somebody explain to me what the security risks might be of allowing cron access to regular users?

Thanks,
Tom

Re: cron - security

harry d brown jr — Mon, 31 Mar 2003 12:49:54 GMT

I guess I would ask: Why do regular users need to use cron? If it's something that they need, then maybe they need to place it into a production process that should be monitored.

my $.02

live free or die
harry

Re: cron - security

Ian Dennison_1 — Mon, 31 Mar 2003 12:55:36 GMT

Because you lose central control of the scheduling process, which can lead in performance problems and workload issues.

Share and Enjoy! Ian

Re: cron - security

Pete Randall — Mon, 31 Mar 2003 13:06:47 GMT

Tom,

As a general rule, I want the developers to come to me and explaing exactly what their process does and exactly why they have to have it regularly scheduled before I'll allow it on MY system. I'm the one that's responsible for the system's performance, so I want to know what's scheduled and when. It's more of a control issue than a security issue to me.

Pete

Re: cron - security

john korterman — Mon, 31 Mar 2003 13:19:33 GMT

Hi Tom,
if the system administrator is not solely responsible for the running of all cron jobs, he/she is not able to detect which jobs look supicious - thus allowing more room for hackers, e.g. via anonymous ftp downloads.

regards,
John K.

Re: cron - security

David_246 — Mon, 31 Mar 2003 13:20:01 GMT

Hi Tom,

In other words, try to minimize the use of cron for regular users. It can affect your system heavily. So if they need the use of cron, explain them their responsibilities.

Sorry, but I don't believe in "it's my system" anymore, that was 20 years ago. Now it has become the bussiness system and we only recommend.

Although, when they start fingerpointing, make sure you have explained the risks, so you can point back :)

Regs David

Re: cron - security

Steven E. Protter — Mon, 31 Mar 2003 13:34:18 GMT

Our policy allows cron for the following users:

root
oracle
sag

The last two users own large database applications that require a complex schedule of events to stay running in an optimized fashion.

Regular users have no need for cron and its a security and performance hazard. Its not like windows where everyone gets a schedule and most don't use it. We don't let our Windows users see or change that schedule either.

Don't consider disallowing cron for regular users, do it.

SEP

Re: cron - security

Ian Dennison_1 — Mon, 31 Mar 2003 14:15:49 GMT

David,

How about "Its MY job to save you from yourself?" In my experience, if you do not assert your responsibility for the OS as the resident expert in that area, any non-SysAdmin armed with a couple of buzzwords can make your life merry hell!

I dislike the "Us vs Them" situation too, but it's "Them" that usually need to adjust their perception.

Share and Enjoy! Ian

Re: cron - security

Pete Randall — Mon, 31 Mar 2003 14:28:01 GMT

And "Them" aren't usually there to help when the system crashes, unless it's to ask "Us" why it's taking so long to get "Their" system back up.

;^)

Re: cron - security

David_246 — Mon, 31 Mar 2003 14:49:00 GMT

Hee, What would do you like more to do ??

Adding a cron user, or bringing a system back online due to a user failure ?

I'dd prefer the more challenging one :)

If you have things covered well enough these are the moments you can get your advantages out of!

Maybe, I like it too much to play, Pete :)

Best Regs David

Re: cron - security

Tom Dawson — Mon, 31 Mar 2003 16:16:50 GMT

All,

Thanks for the replies. You've all pointed out most of the same reasons why I'm disinclined to give out cron access. In our shop, the dispute is over whether to allow it for the oracle user. I'm leaning strongly towards not allowing it so that I can maintain better control over scheduling, and indirectly, system performance.

Thanks again,
Tom