a simple C wrapper for setuid cgi-bin invocations

[Jason Clinton]

On Thu, 2004-05-20 at 17:08, David Nicol wrote:
> Passing function calls over file system sockets means you have
> to come up with an intermediate message passing language and write
> both sides of the conversation, also there is theoretical exploits
> against the listener, and how does the listener start?

There are pre-established interprocess communications systems available
for most script languages that send serialized objects or parameters
over sockets of any type. I don't write PHP so I'm not sure about that
language but I know that Perl, Python and Ruby already have
modules/packages that have the appropriate tools already finished. The
listener would be a daemon probably written in the same language
installed by the system administrator and loaded at boot.

> SetUID shell scripts are forbidden.  I am not sure what level the
> prohibition is enforced at.

The kernel. It's not so much enforced as it is ignored. The script's
shebang line determines which binary is actually 'executed' to process
the syntax of the script. The properties of that parser are the
permissions that are used. You can SUID the perl interpreter (evil!),
for example, to get all your script to run SUID but not on an individual
basis. Perl has a work-around for this called the suidperl that
'emulates an SUID environment'.

> What expolits are possible against a statically-linked, compiled,
> setuid wrapper program?

None directly at the wrapper but at the script itself. If you have a
behemoth of a script that only has one tiny function that needs root
access (like maybe for process table manipulation) the paranoid garden
gnome inside me says seperate the root'ing function from the rest of the
script and only execute that as root. The fear is in the user generating
some unhandled input resulting in privaledge escalation.

> The downside of the approach is that statically linked programs
> are larger and do not take advantage of the memory efficiency of shared
> libraries, but for a function that will be the only thing using the
> library in question that doesn't matter much.

True. I don't really have any objections to your method; just a matter
of style.

> Compare with the
> system resources required to have a listener waiting for a connection
> on a file-system socket (I find the term "unix domain socket" confusing,
> not to me, but in general, as all three words in it are heavily
> overloaded).  The listener needs to run all the time, right?  And the
> communication?  To use run-something-and-collect-its-output invocation
> semantics you need to have a separate client program.  So you don't
> use those semantics, but rather connect and talk with the socket, but
> then that is more complex.

Well, we're running script languages here so I don't think resource
consuption or speed is of much concern. I don't think there's much
overhead in either case, anyways. You're right that it introduces
complexity but some may find the complexity for added checks trade-off
good.

> The point of the simple wrapper is to create one-off setuid tools
> rather than using a blunderbus like sudo.

Yes. But, I disgree with your assessment of sudo. It can be configured
through 'sudoers' to allow a particular user to execute only particular
commands as only another particular user under only particular
conditions. It can be configured with sufficient granularity to prevent
the usual exploits.

> My thoughts are that an explicit message passing interface avoids
> the setuid mechanism but at a price of increased complexity.
> 
> Does that match everyone else's opinions?

Matches mine.