Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 16 Jan 2016 07:47:43 +0000
From: halfdog <>
Subject: Re: Discuss: Daily/weekly cron jobs best practices

Hash: SHA1


Sorry for not finding time to come back earlier.

Tim Brown wrote:
> On Wednesday 06 January 2016 23:06:20 halfdog wrote:
>> Are there more variants, arguments? In my opinion, b) is a good 
>> trade-off between maintainability and security.
> Create scripts with secure permissions, write only to properly
> secured locations and execute as dedicated users with minimal
> privileges. Yes, there will still be problems but a lot of the most
> significant pain points go away.

@all: So there are no objections to propose variant b) in a short
howto for all cron scripts, e.g. too much associated logging
especially if also used for hourly jobs, may upset the IDS/SIEM due to
larger number of SUID-binary calls, risk to give unprivileged process
control over privileged resource already opened/accessed before
changing UID?

"b) run shell script as daemon user and also try to get it secured.
Pro: attackers without code execution possibilities but ability to
make daemon e.g. to create problematic files via the daemon are also

>> Currently the cron scripts seem to be a weak point. I looked at
>> the 8 daily scripts on my machine, 2 of them belonged to the
>> "daemon" example class from above and both were vulnerable to
>> daemon to root privilege escalation, see e.g. [1].
> Not uncommon, we pop almost every UNIX box we touch this way, I
> assume you've seen unix-privesc-check?

I have tried it, but it seems too unspecific. Example from the cron
jobs directory:

W: [privileged_change_privileges] cron-system /etc/cron.daily/dpkg
(root) and does not attempt to change privileges

This is reported nearly for all scripts, for some it might be a
correct finding, for others it is simply wrong (they should really
operate with root permissions in place). So it is not very effective
in pointing at the really problematic scripts.

Of course a project developer could take all the collected warnings as
"checklist", if they might apply to his project's scripts also.

(And they could be made a little more targeted by upc: e.g. report
only if the script uses chown with non-root UIDs or chmod/find/rm ..
on directories not owned by root. But that needs quite a lot of
parsing of the scripts.)

Conclusio on upc in that case could be: Good to scan new project
software as a second line of defense and to get ideas, which errors
one could have made but not helpful to point at specific locations.

- --
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
Version: GnuPG v1


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.