Am 17.04.2012 um 23:55 schrieb Ron Chen: > Just IMO, IFS & PATH should be set by the script itself. But then it is just > my opinion _only_.
I second this and use absolute paths everywhere to be sure. If you know the next jobnumber you could prepare something in the upcoming $TMPDIR beforehand otherwise or leave something there for the epilog... As said: IMO run scripts only under the user's account himself or use a "dummy" account (without SGE manager rights) for special purposes. If it's really necessary to prepare something as root user, I would prefer a suid binary where LD_PRELOAD is ignored already for the same reason. -- Reuti > And there is also LANG, and many other variables that can change the > behaviour of the script somewhat. > > -Ron > > > > ________________________________ > From: Reuti <[email protected]> > To: William Hay <[email protected]> > Cc: [email protected] > Sent: Tuesday, April 17, 2012 5:34 PM > Subject: Re: [gridengine users] Security hole in most versions of Grid Engine > > Am 17.04.2012 um 22:57 schrieb William Hay: > >> There is a security hole in most current versions of Grid Engine. The >> problem occurs when using a dynamically linked program as >> rlogin_daemon, rsh_daemon or qlogin_daemon or when running a >> dynamically linked binary as prolog or epilog with elevated >> privileges. This can be exploited by an ordinary user who submits a >> job using the -v option to set environment variables that control the >> dynamic linker such as >> LD_LIBRARY_PATH or LD_PRELOAD on Linux. This allows the user to run >> arbitrary code with elevated privileges (ie root). > > If you run a prolog/epilog script under root account there might be even more > depending on $PATH or other used (uninitialized) environment variables which > are used therein. > > The best is to run them just as the ordinary user who runs the job anyway. > > NB: Don't forget about start/stop_proc_args ;-) > > -- Reuti > > >> If you use the builtin daemons and don't have prolog or epilog running >> with elevated privileges then you should be safe. >> >> All the major forks (Son of Grid Engine,Open Grid Scheduler, Univa >> Grid Engine and Oracle Grid Engine) and several linux distros have >> prepared patched versions which they should be releasing imminently. >> >> If you can't upgrade immediately then it should be possible to >> protect your system by using a statically linked binary to sanitize >> the environment. On RedHat and compatible versions of Linux busybox >> is linked statically and provides an env command that can be used to >> remove dangerous variables. On Debian and derivatives you need to >> ensure you have the busybox-static package installed rather than plain >> busybox. >> >> You can then protect your code with something like the following: >> prolog root@/sbin/busybox env -u BASH_ENV -u >> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERLLIB -u IFS >> /cm/shared/apps/sge/current/cm/prolog >> epilog root@/sbin/busybox env -u BASH_ENV -u >> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERLLIB -u IFS >> /cm/shared/apps/sge/current/cm/epilog >> rlogin_daemon /sbin/busybox env -u BASH_ENV -u >> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERL5LIB -u PERLLIB -u >> IFS /cm/shared/apps/sge/assist/bin/qrlogind >> qlogin_daemon /sbin/busybox env -u BASH_ENV -u >> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERL5LIB -u PERLLIB -u >> IFS /cm/shared/apps/sge/assist/bin/qlogind >> rsh_daemon /sbin/busybox env -u BASH_ENV -u >> LD_LIBRARY_PATH -u LD_PRELOAD -u PERL5OPT -u PERL5LIB -u PERLLIB -u >> IFS /cm/shared/apps/sge/assist/bin/qrshd >> >> The above examples also remove a few other variables that the >> interpreters we use for our scripts at UCL are sensitive to, >> >> Dave Love(of SoGE) has created a small wrapper program that removes >> the various dynamic linker controlling variables with significantly >> less verbiage which he should be releasing shortly. >> >> >> >> William >> _______________________________________________ >> users mailing list >> [email protected] >> https://gridengine.org/mailman/listinfo/users > > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
