Thanks for your interest!
I guess this is the right forum to ask about the major security issue
remaining. Namely, that mod_privileges may run untrusted code (e.g. a user's
PHP scripts), and a malicious, privileges-aware script could escalate to
anything in EPRIV. In particular, it'll have access to SET_ID.
As it stands, the best solution I have to that is a Perl script to walk the
Apache configuration and check for any script or binary that tries to make
privileges calls and flags them up for the admin. It's a poor second-best to
enforcing security within the program.
A kernel enhancement that would enable me to fix this once-and-for-all would be
a privileges lock, so mod_privileges could wrap an HTTP request in something
like:
* Set privileges and user/group, as configured for the virtualhost
* Lock privileges, so any attempt to change PPRIV will fail
* Run the request, which may include untrusted code
* Release the privileges lock
* Restore defaults.
At its simplest, something like:
{
priv_lock_t *plock = priv_lock();
/* run untrusted code but deny it use of privileges(5) */
priv_unlock(plock);
}
Is anything like this likely to happen in the forseeable future?
Or can anyone suggest a workaround?
--
Nick Kew
--
This message posted from opensolaris.org
