Nick Kew wrote:
> 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?
>
Just to point out the obvious: If you fork a child process to run the
untrusted code, you can reduce the child's Permitted set (or even the
Limit set, if you want to go a step further) to get this effect. Of
course, you might have reasons that make forking a new process unacceptable.
If it needs to be in the same process, I don't quite understand the
semantics of your proposed privilege lock. What is needed in order to
call the unlock routine, and what prevents the untrusted code from doing
that?
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
