SUID layer for Apache CGI implementation...

["Jason A. Dour" <ja...@bcc.louisville.edu>]

-----BEGIN PGP SIGNED MESSAGE-----

This message is being sent jointly to both new-httpd, as well as to the
MotherSoft folks here at the Univ. of Lou. who have helped with suCGI.
I'll be repeating some things I've said previously for benefit of
presenting my position clearly.

. . .

It seems to me that the issue at the heart of this explosive thread is
authenticating the use of an suid back-layer portion for use with Apache. 
If this is not the only *general* issue, then by all means followup this
message with any others you feel are pertinent. 

Authentication between the server and the suid layer needs to be fast.
This is the design goal of Apache in general, and I kept that in mind when
I coded the Beta-Carotene version of mod_sucgi.

My design philosophy for suCGI was this:
	1.  Only call wrapper when absolutely necessary (i.e. userdirs).
	    This was implemented in the Beta-Carotene version.
	2.  Make a messload of paranoia checks *before* calling the
	    wrapper.  This was not implemented in Beta-Carotene.
	3.  Call suid layer.
	4.  Suid layer would allow only a predefined user (i.e. the
	    server user) execute the code.
	5.  Suid layer would watch for OS-level weirdness only.
	6.  Suid layer would *build the path* to the executable.
	    Four, five, and six were all implemented in B-C.

This allowed for userdirs.  It was fairly secure...  It had no paranoia
checks.  The suid layer trusted the server.  It was basically security by
obscurity...  This was not my final goal, however.

To keep with this design philosophy of efficiency, any implementation
should keep with the "stay internal until absolutely necessary" concept.
For this to happen -- especially with allowing use of suCGI by virtual
host or location -- some strong authenticity needs to be implemented so
that only Apache server process can execute the code.  This -- to me --
would assuage my fears of suCGI being exploited.

How to do this?  I have been pondering this, because I was hoping to
bring this functionality to Beta II: Son Of Beta-Carotene.  Here are a few
ideas I had:

* Walk the process tree.  When executed, the wrapper would walk up its
genealogical process tree to verify the parent is actually the allowed
user and is the proper httpd executable image.  To me, this would be
authentic enough (although I'm sure one of you wizards could prove me
wrong).  I like this one best.  My question on this one would be
efficiency.  Am I wrong?

* Pass a simple variable-target authentication pass-phrase.  This could be
something like GMT seconds in a mirrored string.  Or it could be some
other repeatable algorithm.  This is not preferable to the above, however,
because this is another security-by-obscurity technique.

* Verify Apache authenticity by reading some of the server pool for an
authentication key of some sort...  Would preclude suid's access to memory
pools.

* RSA...  Yeah, right.  Never in a million years.  8)

If we can agree upon an automatic authentication scheme...then I think
we'll be fine.  If I am wrong in any of my assumptions, then please let
me know.  If you have comments/ideas on how to implement authentication,
!please! post them.

Jason
+ Jason A. Dour                       jad@bcc.louisville.edu               +
| Programmer Analyst II               http://www.louisville.edu/~jadour01/ |
| Dept. of Radiation Oncology         Finger for Geek Code, PGP Public Key,|
+ University of Louisville            PJ Harvey info, and other stuff...   +

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMbMIKpo1JaC71RLxAQFB3AQAmlx870eoDlWHyxQdVnwlA594reYvp9js
duYzGq3rieNWqtRTFLv1hloOj1Qac1T3t+cB1P5hTo6pMMs74YuOi98kz09uYfgT
0lEf/f8cdB4z9WiRoLcEWMZUc8SzwRDy77Kj0VwKr2cbUGriro1gjZKLyf5FDoQw
6bwl+vZvhSs=
=+YJ+
-----END PGP SIGNATURE-----