system_noshell [PSARC/2009/327 FastTrack timeout 06/05/2009]

[Darren J Moffat]

Sumanth Naropanth wrote:
> The system_noshell() set of functions are _not_ designed to replace
> system(3C), posix_spawn(3C) or exec() family of functions. They are
> designed to be a *secure alternative* to system(3C) while provide the
> ease of use of system(3C). posix_spawn() and fork()/exec()/waitpid() are
> verbose and in the real world, programmers avoid them.

That statement is self contradicting.  The first sentence says it is not 
designed to replace system(3C) yet the second says it is design to be an 
alternative.

It very clearly is designed to be used where system(3C) would be used 
otherwise it wouldn't be called system_noshell()  rather than 
posix_spawn_np() or fork_exec_waitpid_all_in_one()...

> We (security coordination team) often see programmers use system(3C) in
> insecure ways. This may be seen in code as recent as the fast reboot
> putback and the other bugs listed.

Please be very careful about mentioning security bugs as examples, 
remember the PSARC-ext alias is public.

> I would draw parallel to the need for a new strlcpy() interface when we
> already have a strcpy() or a strncpy(). Security guidelines say that
> destination buffer should always be verified and strings should NUL
> terminated, but they aren't in the real world. Hence the need for a
> strlcpy().

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.

-- 
Darren J Moffat