Why not allow all users to schedule jobs with crontabs?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
By setting /etc/cron.allow and/or /etc/cron.deny it's possible to restrict what user is allowed to use crontabs to schedule a cron job to run as that user. At least at my office our SAs default to denying all non-root users the use of crontabs.
My question is why is this a useful default behavior? Scheduling jobs as a user seems a useful feature, especially since it may allow me to configure maintenance steps for a program I'm responsible for (and can log in to the managing user group for) without requesting/needing sudo permissions; thus limiting who needs to be handed elevated permissions.
So I'm wondering why crontabs isn't generally left usable by all users? What risk or security threat is opened by allowing a given user to run crontabs? It doesn't seem like it should lead to a possibility to elevate privileges, as the cron job will run as the user who scheduled it. It could be used to intentionally consume resources by starting a program every minute I suppose, but I don't see why this would be any more of a threat then a traditional forkbomb, which already have protections in place for.
So what is the motivation for preventing users from scheduling tasks with crontabs?
permissions security cron
asked 1 hour ago
dsollen
386315
add a comment |Â
up vote
1
down vote
favorite
By setting /etc/cron.allow and/or /etc/cron.deny it's possible to restrict what user is allowed to use crontabs to schedule a cron job to run as that user. At least at my office our SAs default to denying all non-root users the use of crontabs.
My question is why is this a useful default behavior? Scheduling jobs as a user seems a useful feature, especially since it may allow me to configure maintenance steps for a program I'm responsible for (and can log in to the managing user group for) without requesting/needing sudo permissions; thus limiting who needs to be handed elevated permissions.
So I'm wondering why crontabs isn't generally left usable by all users? What risk or security threat is opened by allowing a given user to run crontabs? It doesn't seem like it should lead to a possibility to elevate privileges, as the cron job will run as the user who scheduled it. It could be used to intentionally consume resources by starting a program every minute I suppose, but I don't see why this would be any more of a threat then a traditional forkbomb, which already have protections in place for.
So what is the motivation for preventing users from scheduling tasks with crontabs?
permissions security cron
asked 1 hour ago
dsollen
386315
2
This seems like a question for your SAs ;-).
– Stephen Kitt
1 hour ago
1
Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop.
– steve
1 hour ago
2
Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them.
– steve
59 mins ago
@StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times.
– dsollen
24 mins ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
By setting /etc/cron.allow and/or /etc/cron.deny it's possible to restrict what user is allowed to use crontabs to schedule a cron job to run as that user. At least at my office our SAs default to denying all non-root users the use of crontabs.
My question is why is this a useful default behavior? Scheduling jobs as a user seems a useful feature, especially since it may allow me to configure maintenance steps for a program I'm responsible for (and can log in to the managing user group for) without requesting/needing sudo permissions; thus limiting who needs to be handed elevated permissions.
So I'm wondering why crontabs isn't generally left usable by all users? What risk or security threat is opened by allowing a given user to run crontabs? It doesn't seem like it should lead to a possibility to elevate privileges, as the cron job will run as the user who scheduled it. It could be used to intentionally consume resources by starting a program every minute I suppose, but I don't see why this would be any more of a threat then a traditional forkbomb, which already have protections in place for.
So what is the motivation for preventing users from scheduling tasks with crontabs?
permissions security cron
asked 1 hour ago
dsollen
386315
By setting /etc/cron.allow and/or /etc/cron.deny it's possible to restrict what user is allowed to use crontabs to schedule a cron job to run as that user. At least at my office our SAs default to denying all non-root users the use of crontabs.
My question is why is this a useful default behavior? Scheduling jobs as a user seems a useful feature, especially since it may allow me to configure maintenance steps for a program I'm responsible for (and can log in to the managing user group for) without requesting/needing sudo permissions; thus limiting who needs to be handed elevated permissions.
So I'm wondering why crontabs isn't generally left usable by all users? What risk or security threat is opened by allowing a given user to run crontabs? It doesn't seem like it should lead to a possibility to elevate privileges, as the cron job will run as the user who scheduled it. It could be used to intentionally consume resources by starting a program every minute I suppose, but I don't see why this would be any more of a threat then a traditional forkbomb, which already have protections in place for.
So what is the motivation for preventing users from scheduling tasks with crontabs?
permissions security cron
permissions security cron
asked 1 hour ago
dsollen
386315
asked 1 hour ago
dsollen
386315
asked 1 hour ago
dsollen
386315
asked 1 hour ago
dsollen
386315
asked 1 hour ago
dsollen
386315
386315
2
This seems like a question for your SAs ;-).
– Stephen Kitt
1 hour ago
1
Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop.
– steve
1 hour ago
2
Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them.
– steve
59 mins ago
@StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times.
– dsollen
24 mins ago
add a comment |Â
2
This seems like a question for your SAs ;-).
– Stephen Kitt
1 hour ago
1
Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop.
– steve
1 hour ago
2
Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them.
– steve
59 mins ago
@StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times.
– dsollen
24 mins ago
2
2
This seems like a question for your SAs ;-).
– Stephen Kitt
1 hour ago
This seems like a question for your SAs ;-).
– Stephen Kitt
1 hour ago
1
1
Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop.
– steve
1 hour ago
Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop.
– steve
1 hour ago
2
2
Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them.
– steve
59 mins ago
Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them.
– steve
59 mins ago
@StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times.
– dsollen
24 mins ago
@StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times.
– dsollen
24 mins ago
add a comment |Â
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f480439%2fwhy-not-allow-all-users-to-schedule-jobs-with-crontabs%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
This seems like a question for your SAs ;-).
– Stephen Kitt
1 hour ago
1
Common to see dedicated app users (e.g. "prod-db1") be allowed to have crontabs, but personal accounts (e.g. "dsollen") to have it disabled. I guess it's to avoid folk introducing critical jobs that run as their own account, and if said account gets removed, or they leave, the whole place goes pop.
– steve
1 hour ago
2
Another reason is to force folk to use the enterprise's chosen scheduler product, e.g. Autosys / Tivoli etc, that gives ops proper visibility of jobs, their output, and ability to hold/reschedule/cancel them.
– steve
59 mins ago
@StephenKitt it would be, if I believed my SA had any clue. They are running hardening scripts dictated to them from the by the corporate gods without a clue of what the scripts do or why. They've had to ask me to explain their hardening scripts a few different times.
– dsollen
24 mins ago