Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

New module mod_allowhandlers / Controlling script execution

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


sf at sfritsch

Apr 21, 2012, 12:48 PM

Post #1 of 4 (353 views)
Permalink
New module mod_allowhandlers / Controlling script execution

Hi,

there is the problem that if modules like mod_status or
mod_proxy_balancer are loaded, all people with permissions to create
.httaccess files can use the status pages by using SetHandler in an
.htaccess file.

I had the idea to create a module like mod_allowmethods, but for
handlers, that allows to restrict which handlers can be used in
particular locations. The following config would e.g. prevent
mod_userdir users from enabling the status pages in their home
directory:

<Location />
AllowHandlers not server-info server-status balancer-manager
</Location>

<Location /server-status>
AllowHandlers all
SetHandler server-status
</Location>

PoC implementation is at
http://people.apache.org/~sf/mod_allowhandlers.c . Any objections
against committing this to trunk?

It does it checks at the end of the fixup hook. This catches all the
common ways to set a handler, but of course it is possible that some
modules may bypass that check (e.g. by changing the handler in an
early handler hook). But IMHO this could be solved by documentation.

The config syntax can probably be improved. Specifying a white-list is
not that easy, because by default every file will have its mime-type
as handler name. Maybe it needs some pattern or regex matching. Any
better ideas?

Another idea where this could be handy: To deny script execution in
some directories. Currently one needs to have a bunch of RemoveHandler
and RemoveType statements for various modules (e.g. application/x-
httpd-php, lua-script). If AllowHandlers allowed to define list
aliases, one could maybe disable them all with a simple command:

AllowHandlers not SCRIPTING

If every scripting module registered its active handler(s) with
mod_allowhandlers, there would even be no need for defining the alias
manually.


Or would it be a better idea to introduce a new "Options ExecScripts"
flag and ask all scripting modules to honor that? Or just recommend
that they use ExecCGI?

Cheers,
Stefan


trawick at gmail

Apr 21, 2012, 1:10 PM

Post #2 of 4 (332 views)
Permalink
Re: New module mod_allowhandlers / Controlling script execution [In reply to]

On Sat, Apr 21, 2012 at 3:48 PM, Stefan Fritsch <sf [at] sfritsch> wrote:
> Hi,
>
> there is the problem that if modules like mod_status or
> mod_proxy_balancer are loaded, all people with permissions to create
> .httaccess files can use the status pages by using SetHandler in an
> .htaccess file.

My 2 cents:

SetHandler shouldn't be used to enable these because it requires an
unnecessary filesystem walk and only requires a very small amount of
code to implement a flag directive. Having ServerStatus On|Off
anywhere in the configuration would disable the check for r->handler
== "status-handler" (migration).

Is the use of handler by these a feature though, such as needing to
let other modules generate these reports by some mechanism other than
using a subrequest for or redirecting to the location where it is
enabled? I don't know how smooth mod_allowhandler would be for that
anyway.

There are other situations where mod_allowhandlers would be helpful,
but I think we could provide a simpler mechanism (flag) for the
several sensitive handlers in bundled modules.

>
> I had the idea to create a module like mod_allowmethods, but for
> handlers, that allows to restrict which handlers can be used in
> particular locations. The following config would e.g. prevent
> mod_userdir users from enabling the status pages in their home
> directory:
>
> <Location />
>  AllowHandlers not server-info server-status balancer-manager
> </Location>
>
> <Location /server-status>
>  AllowHandlers all
>  SetHandler server-status
> </Location>
>
> PoC implementation is at
> http://people.apache.org/~sf/mod_allowhandlers.c . Any objections
> against committing this to trunk?
>
> It does it checks at the end of the fixup hook. This catches all the
> common ways to set a handler, but of course it is possible that some
> modules may bypass that check (e.g. by changing the handler in an
> early handler hook). But IMHO this could be solved by documentation.
>
> The config syntax can probably be improved. Specifying a white-list is
> not that easy, because by default every file will have its mime-type
> as handler name. Maybe it needs some pattern or regex matching. Any
> better ideas?
>
> Another idea where this could be handy: To deny script execution in
> some directories. Currently one needs to have a bunch of RemoveHandler
> and RemoveType statements for various modules (e.g. application/x-
> httpd-php, lua-script). If AllowHandlers allowed to define list
> aliases, one could maybe disable them all with a simple command:
>
> AllowHandlers not SCRIPTING
>
> If every scripting module registered its active handler(s) with
> mod_allowhandlers, there would even be no need for defining the alias
> manually.
>
>
> Or would it be a better idea to introduce a new "Options ExecScripts"
> flag and ask all scripting modules to honor that? Or just recommend
> that they use ExecCGI?
>
> Cheers,
> Stefan



--
Born in Roswell... married an alien...
http://emptyhammock.com/


sf at sfritsch

Nov 6, 2012, 12:44 AM

Post #3 of 4 (240 views)
Permalink
Re: New module mod_allowhandlers / Controlling script execution [In reply to]

Hi,

On Sat, 21 Apr 2012, Jeff Trawick wrote:
>> there is the problem that if modules like mod_status or
>> mod_proxy_balancer are loaded, all people with permissions to create
>> .httaccess files can use the status pages by using SetHandler in an
>> .htaccess file.
>
> My 2 cents:
>
> SetHandler shouldn't be used to enable these because it requires an
> unnecessary filesystem walk and only requires a very small amount of
> code to implement a flag directive. Having ServerStatus On|Off
> anywhere in the configuration would disable the check for r->handler
> == "status-handler" (migration).

I must admit that I haven't looked into why they use the handler for
configuration. But my feeling is that we won't get rid of modules doing
it this in the forseeable future.

> Is the use of handler by these a feature though, such as needing to
> let other modules generate these reports by some mechanism other than
> using a subrequest for or redirecting to the location where it is
> enabled? I don't know how smooth mod_allowhandler would be for that
> anyway.

It does the checks at the end of the fixup hook, which seems to work with
the setups I could think of. But more testing is needed, of course.

> There are other situations where mod_allowhandlers would be helpful,
> but I think we could provide a simpler mechanism (flag) for the
> several sensitive handlers in bundled modules.

I think having it in trunk would be nice to find problems with this
approach. Unless someone disagrees, I am going to commit it. Backport to
2.4 can wait until we are sure that it is a good solution.

Cheers,
Stefan


trawick at gmail

Nov 7, 2012, 2:17 AM

Post #4 of 4 (236 views)
Permalink
Re: New module mod_allowhandlers / Controlling script execution [In reply to]

On Tuesday, November 6, 2012, Stefan Fritsch wrote:

> Hi,
>
> On Sat, 21 Apr 2012, Jeff Trawick wrote:
>
>> there is the problem that if modules like mod_status or
>>> mod_proxy_balancer are loaded, all people with permissions to create
>>> .httaccess files can use the status pages by using SetHandler in an
>>> .htaccess file.
>>>
>>
>> My 2 cents:
>>
>> SetHandler shouldn't be used to enable these because it requires an
>> unnecessary filesystem walk and only requires a very small amount of
>> code to implement a flag directive. Having ServerStatus On|Off
>> anywhere in the configuration would disable the check for r->handler
>> == "status-handler" (migration).
>>
>
> I must admit that I haven't looked into why they use the handler for
> configuration. But my feeling is that we won't get rid of modules doing it
> this in the forseeable future.
>
> Is the use of handler by these a feature though, such as needing to
>> let other modules generate these reports by some mechanism other than
>> using a subrequest for or redirecting to the location where it is
>> enabled? I don't know how smooth mod_allowhandler would be for that
>> anyway.
>>
>
> It does the checks at the end of the fixup hook, which seems to work with
> the setups I could think of. But more testing is needed, of course.
>
> There are other situations where mod_allowhandlers would be helpful,
>> but I think we could provide a simpler mechanism (flag) for the
>> several sensitive handlers in bundled modules.
>>
>
> I think having it in trunk would be nice to find problems with this
> approach. Unless someone disagrees, I am going to commit it. Backport to
> 2.4 can wait until we are sure that it is a good solution.


+1


>
> Cheers,
> Stefan
>


--
Born in Roswell... married an alien...
http://emptyhammock.com/

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.