| 1 |
On 29/01/2017 03:08, Ian Zimmerman wrote: |
| 2 |
> On 2017-01-28 22:40, Alan McKinnon wrote: |
| 3 |
> |
| 4 |
>> There are valid cases where denying read access to crontabs is |
| 5 |
>> desirable, for example a command run from cron requires a password and |
| 6 |
>> the only way to provide it is on the command line. Such programs |
| 7 |
>> exist, and the cron app provides a way to limit exposure. |
| 8 |
> |
| 9 |
> I have to disagree. By this argument, /sbin and /usr/sbin shouldn't be |
| 10 |
> readable either. |
| 11 |
|
| 12 |
The whole Unix file ownership and permissions area is one huge |
| 13 |
compromise, mostly caused by groups and that there can be only one group |
| 14 |
owner and it cannot be null |
| 15 |
|
| 16 |
/sbin and /usr/sbin being non-readable is a silly argument as there is |
| 17 |
NOTHING root-specific about them. Those directories are just a convenient |
| 18 |
way to get them into root's PATH and out of everyone else's PATH. |
| 19 |
|
| 20 |
> The password can be in a file, and read into a shell variable. |
| 21 |
|
| 22 |
I already said cron has to launch any script or command that exists. |
| 23 |
Cron cannot dictate what form a command must have as the command already |
| 24 |
exists, it can only try and improve things overall |
| 25 |
|
| 26 |
|
| 27 |
> Apart from that, there's also Frank's objection. Maybe /proc/cmdline |
| 28 |
> can be disabled, though. In that case ps wouldn't be able to see the |
| 29 |
> arguments. |
| 30 |
|
| 31 |
Yes there is that. A sysadmin implementing cron has 3 options: |
| 32 |
|
| 33 |
- pretend there is no problem and ignore it |
| 34 |
- devise a bunch of workarounds that will likely be tricky to use |
| 35 |
- use file permissions to reduce exposure but not eliminate it. It's not |
| 36 |
perfect, it's just better. |
| 37 |
|
| 38 |
I'm not arguing for perfection, I'm just giving examples of improvement |
| 39 |
|
| 40 |
|
| 41 |
-- |
| 42 |
Alan McKinnon |
| 43 |
alan.mckinnon@×××××.com |
Archives