Date: Sat, 16 Jan 2016 07:47:43 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Re: Discuss: Daily/weekly cron jobs best practices -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, 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 blocked." >> 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. . > > 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. - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaZ9ZQACgkQxFmThv7tq+7b2gCfWCZSkkSNtEETujorj3+4qpd2 gM8AmgLOPLiErmk36/BJNYRSURG02BWf =X8za -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ