> Which again re-enforces that system_noshell() *is* intended to be a 
> replacement for system(3C).
> 
> I have not problem with providing a variant of system(3C) that is more 
> secure.  However I'm not convinced that a new symbol - and thus changes 
> to existing code to use it.  Is the best way to do it.  I wonder if this 
> can be done more like the non exec stack, ie something that gets set at 
> build time.

        I too have no real problem with a more secure convenience function
        version of system(3).  I'm not convinced that this is it.  Or without
        changing to existing source code that system_noshell(3) will really
        provide benefit sought.
        Is part of this project to go through Solaris and fix callers
        of system(3)?  I didn't see that in the proposal.
        
        I'm concerned about statements like:


     "SN_RESETIDS     If this flag is set, the file is executed by resetting
                     the effective user ID and the effective group ID of the
                     child process executing the file to the real user ID and
                     the real group ID of the parent.

     The system_noshell() function resets the user and group IDs to those
     of the real user, when used in setuid binaries. Use system_noshell_x()
     and system_noshell_xv() to override this behavior. There will be no
     change in privileges when the system_noshell() function is used in
     non setuid binaries."


        What does setuid have to do with privilege?  Is this just imprecision
        and the intent is setuid 0 -- thus implying all zone "forced"
        privileges?  Why wouldn't I want the ability to reset the privileges
        to basic (or some priv set passed in)?
        I'd think a convenince function should have similar ability to

        if ((pid = fork()) != 0) {
                /* parent */
                while (pid != waitpid(pid, &status)) {
                        continue;
                }
                return (WEXITSTATUS(status);
        } else if (pid  == -1) {
                /* couldn't fork */
                return (-1);
        }

        /* child */

        if (resetuids) {
                (void) setuid(getuid());
                (void) setgid(getgid());
        }
        if (resetprivs) {
                (void) setppriv(PRIV_SET, PRIV_LIMIT, basic);
        }
        if (execv(path, argv) == -1) {
                _exit(127)
        }
        /* NOPATH */


        The project team should note that setuid 0 is not the only way
        a program gains privilege.  pfexec(1) -P and pfexec from a granted
        Rigths Profile, svc.startd method_context are examples of other
        ways.  Is the intent to help these programs also?

        Perhaps I've missed something as to why system_noshell() is being
        proposed or proposed as it is.

        Maybe some concrete usage examples (see Glenn's comment)).

Gary..

Reply via email to