PFSYSEUID and RHEL 5

[Fairlight]

With neither thought nor caution, Dave blurted:
> Egads what a mess!  From man system:
>       Do  not  use  system()  from a program with set-user-ID or set-group-ID
>       privileges, because strange values for some environment variables might
>       be  used  to subvert system integrity.  Use the exec(3) family of func$B!>(B
>       tions instead, but not execlp(3) or execvp(3).  system() will  not,  in
>       fact,  work  properly  from  programs  with set-user-ID or set-group-ID
>       privileges on systems on which /bin/sh is bash version 2, since bash  2
>       drops  privileges  on startup.  (Debian uses a modified bash which does
>       not do this when invoked as sh.)

I'd contend that the man page is improperly worded.  The system() function
works just fine from inside SUID/SGID programs.  It's the subsequent
intervening shell that is problematic.

They make a good point via a hint there--another solution would be to just
quickly hack bash to either not drop privs, or (probably easier to find)
pretend that it always got the requisite flag that disables priv dropping.

> So... do not use system() from an suid executable (like, say, dclerk)
> where /bin/sh is bash?  Essentially don't use SYSTEM on Linux.  Thanks
> for pointing this out Fairlight.  Though I'm more frustrated than ever
> now this closes a few avenues we've been wasting our time on.

Essentially, yes.  Well, no.  You can use it, just don't expect the
programs to be run SUID, or any resultant created files to be owned by
filepro.  In truth, the SCO model was always a broken model in terms of
security.  Think about it--with the ability to spin off anything with
SYSTEM() and run it as filepro, even if you lock someone directly into
filepro and don't let them exit the fP environment, if they have access to
define processing, they can delete/fold/spindle/mutilate any file owned by
filepro--including the filepro binaries themselves.  It's an inherent
security loophole subject to abuse on platforms like SCO.

Essentially, the Bash 2 behaviour is proper and security-minded.  It's just
inconvenient when you're coming from an environment that's not.

> Just wondering... It's been suggested to me that ksh may be the way to
> go.  In my tests replacing /bin/sh with a symlink to /bin/ksh gives
> our developers the behavior they expect (files created with SYSTEM
> show an owner of filepro).  I'm a bit scared that re-symlinking
> /bin/sh is going to cause some unforeseen breakages somewhere else.
> Has anyone else running ksh as /bin/sh and what should we look out
> for?

I personally wouldn't risk it.  Some of the startup scripts may assume bash
syntax/features--just like SCO assumed your default shell for root was
/bin/sh and you couldn't replace it with tcsh without breaking a good
percentage of the startup sequence.  (Did that once...didn't like it.)

As above, I'd sooner hack and recompile bash.  I'd do that well before
I'd replace bash with ksh for /bin/sh.  Bash isn't 100% compliant with
anything, so you're taking your chances if you replace it with anything
other than a tweaked version of itself.  You can try it, I just think it's
a little risky.

mark->