Re: set-uid root files in bin/

It's a fair cop, guv. I omitted tbinit and tbmode; both of those need to be SUID root. >From: ptp@fallschurch-acirs2.army.mil (Paul Pryor) >Date: Tue, 14 Feb 1995 15:14:10 -0500 (EST) > >I checked off list of executables which are to be left set-uid root, >and was not sure about the last two files, tbinit, and tbmode, since >you didn't say they need to be set-uid root. I just wanted to double >check before I turn off the set-uid root bits for these two. > >Here's list of all set-uid root files in bin/ and lib/ directories: > >bin: >---s--s--x 1 root informix 12964 Dec 31 1969 sgidsh >---s--s--x 1 root informix 378446 Dec 31 1969 tbinit >---s--s--x 1 root informix 326320 Dec 31 1969 tbmode >---s--s--x 1 root informix 612780 Dec 31 1969 tbmonitor >---s--s--x 1 root informix 347026 Dec 31 1969 tbspaces > >lib: >---s--s--x 1 root informix 1124110 Dec 31 1969 sqlturbo > >I'm glad Informix doesn't take the 'blunderbus' approach when it comes >to setting the executables with set-uid root permissions, but I can >never be sure what precautions Informix takes when the executables are >running, eg, forcing IFS to '' when forking a shell while running as >root, turning off set-uid root temporarily, and switch back to set-uid >root only when necessary, etc. tbinit can only be run by root or informix; likewise tbmode and tbspaces. The SUID-ness presents minimal risks, regardless of what the programs actually do. sqlturbo only runs other programs in response to a SYSTEM command inside a stored procedure. By the time that is being run, the UID of sqlturbo is the same as the UID of the person who ran the application; sqlturbo turns off its SUID-root-ness (to coin a phrase) as quickly as it can. Whether you could exploit IFS loopholes to get sqlturbo to run something other than sgidsh in such circumstances is debatable; I suspect that you'd run into other problems first, but ... That leaves just tbmonitor. This can be run by informix in the powerful administrative mode, and by everyone else (including root) in the status-only mode. I haven't delved into the source code to find out what programs, if any, it runs, and how it does so. In principle, it only runs things like tbmode and tbspaces, and these take care of permissions themselves, or the shell in response to exclamation marks. That means that the programs could be run after the forked process has reset its effective UID (and GID) to the real UID (and GID). This would avoid giving a user privileges other than those they have anyway. I am not claiming that the programs are absolutely tamper-proof, but they certainly resist casual tampering efforts. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>