John.Zolnowsky at Sun.COM wrote:
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> system_noshell
> 1.2. Name of Document Author/Supplier:
> Author: Sumanth Naropanth
> 1.3 Date of This Document:
> 29 May, 2009
> 4. Technical Description
> I'm sponsoring this fasttrack on behalf of Sumanth Naropanth.
> This case will time out June 5, 2009.
>
> SUMMARY:
> Implementation of new C library functions -- system_noshell(3C)
> (and variants) to work as secure alternatives to the system(3C)
> function, to proactively prevent security vulnerabilities resulting
> from unintended invocation of user shell.
>
> PROBLEM:
> The system(3C) function call invokes the user shell to execute the
> argument string supplied to it. This function, however is frequently
> used to execute a file when there is no need to invoke the shell at
> all. Searching through the OpenSolaris source files for the usage of
> the system(3C) function produces over 200 hits, a large number of
> which are binary executions which should rather be done in a safer
> way via the exec(2) family of system calls.
>
I may have missed something here, but how does the implementation of
system_noshell (et al) help here? If the app abuses system(3C) and, as
you say, should be modified to use an exec(2) variant, why should the
app use system_noshell() instead of exec()?
Do other OSs implement system_noshell? If I were an app writer and used
system_noshell, would that mean my app needs modifications to be
portable to, say, Linux where I would have had no problem with the
exec() call?
Basically, what does system_noshell give me that exec() doesn't? (I
think I can see one answer to this, but want to make sure I've got the
right end of the stick). Is this just a wrapper to provide a simple way
of saying to the system "go run this, but do it for me safely"?
IMO, this would be more useful as an interposer library (in a similar
way to libwatchmalloc, etc...) which could be used to override the
default system(3C) call with a safer version. That way, the
application(s) in question do not need to be modified, and the admin can
make a system()-calling app safe(r). [ I am making the assumption that
this is possible - I've not checked ]
In an ideal world, I guess the app should be bugged and changed to use
something safer that system(), but again that comes back to the first
point - if the app is to be modified, why not just modify it to use exec?
Brian
--
Brian Ruthven Sun Microsystems UK
Solaris Revenue Product Engineering Tel: +44 (0)1252 422 312
Sparc House, Guillemont Park, Camberley, GU17 9QG
