ENV03-C. Sanitize the environment when invoking external programs

There is some misinformation in the parts that talk about IFS.  The advice to set IFS to its standard value is fine, but the specifics of why this is needed are wrong.  It says IFS "is used by the sh and bash shells to determine which characters separate command line arguments".  Ancient Bourne shells used to do this, but modern shells do not.  Not even the Bourne shell that Solaris still has as /bin/sh does it.  Modern shells only use IFS to do field splitting on the results of parameter expansion, command substitution, and arithmetic expansion (as required by POSIX).

The example given of system("/bin/ls") is not affected by IFS. However, something like
system("ls dir.`date +%Y%m%d`") would be.

_PATH_STDPATH and paths.h are non-standard.  BSD and Linux systems have them, but many other systems do not.  The portable way to obtain a standard PATH value is to use confstr() with _CS_PATH.

There are a couple of issues with the parts that talk about clearing the environment and preserving some variables.

1. POSIX says "If the application modifies environ or the pointers to which it points, the behavior of getenv() is undefined."  The proper way to remove unwanted variables is to use unsetenv().

2. Some systems have an environment variable that is needed to ensure conforming behaviour.  For example AIX needs XPG_SUS_ENV,  HP-UX needs UNIX95, IRIX needs _XPG, UnixWare needs POSIX2, and Linux needs POSIXLY_CORRECT.  Clearing these variables could change the behaviour of some interfaces or utilities in subtle ways that could make the application misbehave, or even have security implications. The new revision of POSIX will provide a standard way to query which variables are needed.  It gives an example of how to use it via getconf when creating a new environment with env -i:

 env -i $(getconf V7_ENV) PATH="$(getconf PATH)" command

but the same information can also be obtained from confstr() using _CS_V7_ENV. 

There is a lot of work required on this entry - as indicated by the comments.  The comments from Geoff about IFS are mostly valid - but the modern shells (including Solaris /bin/sh) reset IFS on startup and only pay attention to changes that you make in the script.  So, the 'may have issues' example would have to include an assignment to IFS.  Of course, if the system() function invokes the command processor specified by $SHELL then there's another bag'o'worms to deal with.

Conflating the value of $HOME with the entry in the password database is a common mistake -- the two need not be the same.  Further, ~ and ~username do not necessarily equate:

$ echo ~ ~jleffler
/work1/jleffler /u/jleffler
$

The value of ~ corresponds to $HOME; the value of ~jleffler corresponds to the value in the password database.  I usually set my home directory off the NFS auto-mounted directory specified in the password database onto a local file system.  It means I have an incredibly complex (possibly over-complex) system for configuring my environment.  Almost all programs work correctly - taking $HOME to mean what I said.  I do work with some that have a fixation that my home directory must be the value in the password database - they are a nuisance.

Suffice to say, this recommendation is not yet ready for prime time. 

I believe all the issues are addressed now.

Another compliant solution could be created to illustrate the discussed _CS_V7_ENV if there is time, but this is not critical, since there is not yet a system on which such an example could be tested.

In general, programs should be designed to ignore environment variables.  Unfortunately, many (POSIX) systems use them in surprising ways.  The worst example is the use of LD_LIBRARY_PATH to override the link-time and default search path for shared libraries, which allows a user to substitute his own library that does whatever he wants.  The only defense against this seems to be to bind the libraries into the executable image "statically", i.e. ld -Bstatic.  There should be a rule "Don't use shared/dynamically-linked libraries".  Unfortunately on Windows it is hard to avoid them.
In the system("rm ~/.config") example, the comopliant solution is incomplete. At the ery least it should be followed by /...use pwd->pw_dir to construct the path.../

is it just me, or does all of this only matter if the program is running with higher privileges than the caller? (setuid/setgid) we should probably make that more clear, as it stands, this rule implies that all programs should rehash their environment before doing anything useless (which kind of defeats the whole purpose of having an environment...)

Having a Rose checker algorithm that relies on clearenv() does not seem very useful, since clearenv() is non-standard.

It looks like the provided implementation of clearenv() will never terminate. The loop condition checks to see if env0!=0, which if true once will always be true since the value of env0 is never modified in the loop.

It looks like clearenv() should be implemented as:

extern char **environ;

int clearenv(void) {
  static char *namebuf = NULL;
  static size_t lastlen = 0;
  unsigned int i = 0;
  
  while (environ != NULL && environ[i] != NULL) {
    size_t len = strcspn(environ[i], "=");
    if (len == 0) {
      /* Handle empty variable name (corrupted environ[]) */
    }
    if (len > lastlen) {
      namebuf = realloc(namebuf, len+1);
      if (namebuf == NULL) {
        /* Handle error */
      }
      lastlen = len;
    }
    memcpy(namebuf, environ[i], len);
    namebuf[len] = '\0';
    if (unsetenv(namebuf) == -1) {
      /* Handle error */
    }
    i++;
  }
  return 0;
}

This guideline is stated to be a more specific instance of STR02-C. Sanitize data passed to complex subsystems

That guideline has the following "Automated Detection" section:

Fortify SCA Version 5.0 can detect violations of this rule.

Klocwork Version 8.0.4.16 can detect violations of this rule with the NNTS.TAINTED and SV.TAINTED.INJECTION checkers.

Do these checkers also identify violations of this guideline?

I find the Compliant Solution (POSIX, ls) rather contrived. It would be error-prone for a process to clear its own environment before invoking system(). A safer approach would be to invoke fork() followed by a call to execve() with the absolute pathname of the program and a sanitized environment.