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

Mailing List Archive: Apache: Dev

mpm-itk and upstream Apache, once again

  

 
First page Previous page 1 2 Next page Last page  View All Apache dev RSS feed   Index | Next | Previous | View Threaded


sgunderson at bigfoot

Jul 19, 2012, 7:17 AM

Post #1 of 36 (1277 views)
Permalink
mpm-itk and upstream Apache, once again
Hi,

I've asked previously on this list about inclusion of mpm-itk
(http://mpm-itk.sesse.net/) into upstream Apache; previously, the requests
have died down, mostly over discussions on security (mpm-itk does
configuration and request parsing as uid 0, although with very limited
capabilities) and arguments along the lines of “there is no need”,
e.g. various people I've talked to feel that there are other adequate
solutions for the problem, including suexec, multiple Apache instances with
reverse proxying, or some GSoC project.
(http://wiki.apache.org/httpd/PrivilegeSeparation even claims you can
keep administrators from reading each others' sites simply by setting
setting chmod 0640, completely ignoring the case where you can run PHP code
or CGI scripts!)

However, since then mod_privileges have entered Apache trunk, which gives
similar functionality (contradicting the arguments about “no need”), is very
similar in terms of security model (contradicting the arguments about “the
model is too insecure”), but is Solaris-specific, has less functionality (it
lacks per-vhost nicing and per-vhost client limits), and generally seems to
be less mature (e.g., as far as I can see, it fails to adequately handle the
case where the client goes to a different-uid vhost and .htaccess thus is
not readable).

Furthermore, Fedora has recently accepted the mpm-itk patch into their Apache
packages. This means that nearly every major distributor of Apache now
supports mpm-itk; in particular, Arch, Debian, Fedora, FreeBSD ports, Gentoo,
Mandriva, openSUSE and Ubuntu all include mpm-itk. I do not know of any
module with a similar status, and having them all integrate the patch
separately instead of simply having it in mainline seems wasteful.

mpm-itk has, despite its non-mainline status, been in production in large
sites for many years (it has been under development since 2005), and should
at this point be considered mature. What would be needed to get it into mainline?

/* Steinar */
--
Homepage: http://www.sesse.net/


trawick at gmail

Jul 19, 2012, 8:27 AM

Post #2 of 36 (1259 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 10:17 AM, Steinar H. Gunderson
<sgunderson [at] bigfoot> wrote:
> Hi,
>
> I've asked previously on this list about inclusion of mpm-itk
> (http://mpm-itk.sesse.net/) into upstream Apache; previously, the requests
> have died down, mostly over discussions on security (mpm-itk does
> configuration and request parsing as uid 0, although with very limited
> capabilities) and arguments along the lines of there is no need,
> e.g. various people I've talked to feel that there are other adequate
> solutions for the problem, including suexec, multiple Apache instances with
> reverse proxying, or some GSoC project.
> (http://wiki.apache.org/httpd/PrivilegeSeparation even claims you can
> keep administrators from reading each others' sites simply by setting
> setting chmod 0640, completely ignoring the case where you can run PHP code
> or CGI scripts!)
>
> However, since then mod_privileges have entered Apache trunk, which gives
> similar functionality (contradicting the arguments about no need), is very
> similar in terms of security model (contradicting the arguments about the
> model is too insecure), but is Solaris-specific, has less functionality (it
> lacks per-vhost nicing and per-vhost client limits), and generally seems to
> be less mature (e.g., as far as I can see, it fails to adequately handle the
> case where the client goes to a different-uid vhost and .htaccess thus is
> not readable).
>
> Furthermore, Fedora has recently accepted the mpm-itk patch into their Apache
> packages. This means that nearly every major distributor of Apache now
> supports mpm-itk; in particular, Arch, Debian, Fedora, FreeBSD ports, Gentoo,
> Mandriva, openSUSE and Ubuntu all include mpm-itk. I do not know of any
> module with a similar status, and having them all integrate the patch
> separately instead of simply having it in mainline seems wasteful.
>
> mpm-itk has, despite its non-mainline status, been in production in large
> sites for many years (it has been under development since 2005), and should
> at this point be considered mature. What would be needed to get it into mainline?

I personally don't want to think about getting mpm-itk into mainline,
but I am interested in the following, which is largely a prerequisite
to what you requested:

What changes are needed to httpd trunk so that you can build mpm-itk
with apxs and enable it via LoadModule, such that mpm-itk is fully
functional? As I'm sure you're aware, prefork, worker, and event are
all untied from core enough to support that in httpd >= 2.4.

>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>



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


sgunderson at bigfoot

Jul 19, 2012, 8:38 AM

Post #3 of 36 (1258 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 11:27:04AM -0400, Jeff Trawick wrote:
> What changes are needed to httpd trunk so that you can build mpm-itk
> with apxs and enable it via LoadModule, such that mpm-itk is fully
> functional? As I'm sure you're aware, prefork, worker, and event are
> all untied from core enough to support that in httpd >= 2.4.

We'd need:

1. A hook right after merging the perdir config.
2. Fixes to get Apache to drop the connection if it detects
(during .htaccess lookup) that it would need to change the uid.

Both patches are simple, although for #2 to be truly generic (ie. be usable
by mod_privileges as well) we'd need some sort of signalling mechanism saying
“we have switched uids and cannot switch back”, which then both
mod_privileges (in secure mode) and mpm-itk could set.

I've attached the current versions of both patches from my current Apache 2.4
patch set; you can see the “ap_running_under_mpm_itk” variable which would
probably need to be replaced by ap_mpm_query() or similar.

/* Steinar */
--
Homepage: http://www.sesse.net/
Attachments: 06-hook-just-after-merging-perdir-config.patch (1.92 KB)
  11-fix-htaccess-reads-for-persistent-connections.patch (4.68 KB)


nick at webthing

Jul 19, 2012, 9:26 AM

Post #4 of 36 (1252 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, 19 Jul 2012 17:38:31 +0200
"Steinar H. Gunderson" <sgunderson [at] bigfoot> wrote:

> On Thu, Jul 19, 2012 at 11:27:04AM -0400, Jeff Trawick wrote:
> > What changes are needed to httpd trunk so that you can build mpm-itk
> > with apxs and enable it via LoadModule, such that mpm-itk is fully
> > functional? As I'm sure you're aware, prefork, worker, and event are
> > all untied from core enough to support that in httpd >= 2.4.
>
> We'd need:
>
> 1. A hook right after merging the perdir config.

Does it run per-dir config as root?

How does it protect against such potential attacks as running an
external program as root through a RewriteMap running earlier
than the directory walk?

Given that the header_parser runs immediately after directory
config in request.c, are there specific reasons (beyond inelegance)
not to run as header_parser with REALLY_FIRST?

> 2. Fixes to get Apache to drop the connection if it detects
> (during .htaccess lookup) that it would need to change the uid.

Dropping the connection gratuitously breaks HTTP, and so has no
place in httpd (of course, a third-party module sets its own rules).
Would it need a core patch to return an Internal Server Error (500)?

--
Nick Kew


trawick at gmail

Jul 19, 2012, 9:43 AM

Post #5 of 36 (1252 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 11:38 AM, Steinar H. Gunderson
<sgunderson [at] bigfoot> wrote:
> On Thu, Jul 19, 2012 at 11:27:04AM -0400, Jeff Trawick wrote:
>> What changes are needed to httpd trunk so that you can build mpm-itk
>> with apxs and enable it via LoadModule, such that mpm-itk is fully
>> functional? As I'm sure you're aware, prefork, worker, and event are
>> all untied from core enough to support that in httpd >= 2.4.
>
> We'd need:
>
> 1. A hook right after merging the perdir config.
> 2. Fixes to get Apache to drop the connection if it detects
> (during .htaccess lookup) that it would need to change the uid.
>
> Both patches are simple, although for #2 to be truly generic (ie. be usable
> by mod_privileges as well) we'd need some sort of signalling mechanism saying
> we have switched uids and cannot switch back, which then both
> mod_privileges (in secure mode) and mpm-itk could set.
>
> I've attached the current versions of both patches from my current Apache 2.4
> patch set; you can see the ap_running_under_mpm_itk variable which would
> probably need to be replaced by ap_mpm_query() or similar.

I suspect that an ap_hook_stat() to be called from directory walk
would allow itk to keep its odd processing private, and might be
useful to other modules as well.

For ap_parse_htaccess(), I suspect that some mechanism for plugging
into the whole htaccess-is-a-file mess could enable interesting
features beyond mpm-itk, but perhaps the minimum is the appropriate
solution: Use a hook in place of a direct call to ap_pcfg_openfile().

The post-perdir-config hook looks reasonable to me.

--

While the usefulness of a new hook or that by other existing modules
(mod_privileges perhaps) to solve a current problem is interesting, it
should be sufficient to determine that a new hook can be put to good
use by some theoretical module.

>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>



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


isoma at jellybaby

Jul 19, 2012, 10:07 AM

Post #6 of 36 (1256 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On 19 Jul 2012, at 17:26, Nick Kew wrote:

>> 2. Fixes to get Apache to drop the connection if it detects (during .htaccess lookup) that it would need to change the uid.
>
> Dropping the connection gratuitously breaks HTTP, and so has no place in httpd (of course, a third-party module sets its own rules). Would it need a core patch to return an Internal Server Error (500)?

Vanilla httpd does this all the time after a timed-out keepalive. The client cannot make any assumptions about the configured timeout, and can't tell whether the dropped connection is due to a genuine timeout or a UID mismatch between the previous and current request.

--
Tim Bannister - +44 7980408788 - isoma [at] jellybaby
Attachments: smime.p7s (4.29 KB)


minfrin at sharp

Jul 19, 2012, 10:22 AM

Post #7 of 36 (1252 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On 19 Jul 2012, at 18:07, Tim Bannister <isoma [at] jellybaby> wrote:

> On 19 Jul 2012, at 17:26, Nick Kew wrote:
>
>>> 2. Fixes to get Apache to drop the connection if it detects (during .htaccess lookup) that it would need to change the uid.
>>
>> Dropping the connection gratuitously breaks HTTP, and so has no place in httpd (of course, a third-party module sets its own rules). Would it need a core patch to return an Internal Server Error (500)?
>
> Vanilla httpd does this all the time… after a timed-out keepalive. The client cannot make any assumptions about the configured timeout, and can't tell whether the dropped connection is due to a genuine timeout or a UID mismatch between the previous and current request.

I would hate to have to troubleshoot this - two completely independent behaviors, with the same symptom but completely different cause.

Nick is right, a 500 is the right thing to do here.

Regards,
Graham
--


isoma at jellybaby

Jul 19, 2012, 10:54 AM

Post #8 of 36 (1250 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On 19 Jul 2012, at 18:22, Graham Leggett wrote:

> I would hate to have to troubleshoot this - two completely independent behaviors, with the same symptom but completely different cause.
>
> Nick is right, a 500 is the right thing to do here.

I'm really not convinced. I'd expect a user agent to retry in the keepalive-disconnect case, whereas a 500 response usually gets displayed to the user. Very different experiences.

I think there's a case for leaving itk separate, a bit like mod_fcgid. It is a bit unusual and troubleshooting won't be straightforward.

--
Tim Bannister isoma [at] jellybaby
Attachments: smime.p7s (4.29 KB)


sesse at samfundet

Jul 20, 2012, 9:25 AM

Post #9 of 36 (1255 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 05:26:23PM +0100, Nick Kew wrote:
> Does it run per-dir config as root?

Yes, although it has very limited root rights; it can setuid and it can
read arbitrary files and directories, but it cannot e.g. load kernel modules
or write to arbitrary files.

> How does it protect against such potential attacks as running an
> external program as root through a RewriteMap running earlier
> than the directory walk?

If the administrator (who will naturally be root) sets up such a RewriteMap,
it will naturally be executed as (limited) root. RewriteMap is not supported
in .htaccess.

Note that this is very much comparable to mod_privileges, for both cases.
With seccomp v2 support (coming in Linux 3.5), we can also restrict the uid
ranges to setuid to.

> Given that the header_parser runs immediately after directory
> config in request.c, are there specific reasons (beyond inelegance)
> not to run as header_parser with REALLY_FIRST?

As far as I understand, we don't have the per-directory configuration merged
at that stage. Supporting separate vhosts in a more fine-grained fashion
than <VirtualHost> was a common request (we now support <Directory> and
<Location>, and I'm looking at integrating ap_expr support for 2.4).

> Dropping the connection gratuitously breaks HTTP, and so has no
> place in httpd (of course, a third-party module sets its own rules).

On the contrary, RFC 2616 explicitly allows this behavior; section 8.1.4
states “A client, server, or proxy MAY close the transport connection at any
time. [...] This means that clients, servers, and proxies MUST be able to
recover from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests without
user interaction so long as the request sequence is idempotent (see section
9.1.2).”

All clients that I know of deal with this without any problems; the only
problem I've ever seen is with old versions of Varnish, and that has long
since been fixed as a bug in Varnish.

> Would it need a core patch to return an Internal Server Error (500)?

Without any patches, it will return 403. In any case, 500 or other HTTP error
messages are not very useful; it breaks several useful use cases, such as

a) A user browsing to vhost-with-uid-1001, and then before the timeout
follows a link to vhost-with-uid-1002.
b) vhost-with-uid-1001 includes an image (or other media) from
vhost-with-uid-1002.
c) A proxy (reverse or otherwise) or web crawler needs to access
vhost-with-uid-1001 and vhost-with-uid-1002 in quick succession
(similar to a) ).

These are not hypothetical situations; clients actually do this, and they
will return hard errors to the user if they are presented with HTTP error
messages.

/* Steinar */
--
Homepage: http://www.sesse.net/


sesse at samfundet

Jul 20, 2012, 9:26 AM

Post #10 of 36 (1254 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 06:54:56PM +0100, Tim Bannister wrote:
> I think there's a case for leaving itk separate, a bit like mod_fcgid. It
> is a bit unusual and troubleshooting won't be straightforward.

Why would you keep mpm-itk separate but mod_privileges not?

/* Steinar */
--
Homepage: http://www.sesse.net/


trawick at gmail

Jul 20, 2012, 10:48 AM

Post #11 of 36 (1252 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Fri, Jul 20, 2012 at 12:26 PM, Steinar H. Gunderson
<sesse [at] samfundet> wrote:
> On Thu, Jul 19, 2012 at 06:54:56PM +0100, Tim Bannister wrote:
>> I think there's a case for leaving itk separate, a bit like mod_fcgid. It
>> is a bit unusual and troubleshooting won't be straightforward.
>
> Why would you keep mpm-itk separate but mod_privileges not?

IMO it is not a very relevant question given the big picture:

* Most modules written for httpd are not bundled with the server or
otherwise hosted/developed at the ASF.
* mod_privileges is for a minority server operating system and is not
used extensively even there.
* You won't find much rhyme or reason to why some modules are bundled
and some are not other than whether or the author has commit access,
and even then there isn't much consistency.

As far as mpm-itk: A few hooks can be added to httpd core so that it
can be enabled just like other modules*, whether or not anyone here
cares about the implementation details.

*Of course that isn't really true of the popular 2.2.x branch, but I
don't think it is realistic to hope that mpm-itk would ever make it to
2.2.x anyway.

By the way, did any other httpd-ers have a look at those patches and
have suggestions for what hooks could be added?


sesse at samfundet

Jul 20, 2012, 10:56 AM

Post #12 of 36 (1252 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Fri, Jul 20, 2012 at 01:48:33PM -0400, Jeff Trawick wrote:
>> Why would you keep mpm-itk separate but mod_privileges not?
>
> IMO it is not a very relevant question given the big picture:
>
> * Most modules written for httpd are not bundled with the server or
> otherwise hosted/developed at the ASF.
> * mod_privileges is for a minority server operating system and is not
> used extensively even there.
> * You won't find much rhyme or reason to why some modules are bundled
> and some are not other than whether or the author has commit access,
> and even then there isn't much consistency.

I'm not sure if I understand this. Should not “the module is considered
useful” be a better criteria than “the module is written by someone with
commit access”? And how can “the module has a very small user base” be an
argument _for_ keeping it in trunk, and the more popular one out?

If nothing else, should not a module that's patched in by a significant
fraction be pulled into the main tree, to lighten the burden on distributors?

> As far as mpm-itk: A few hooks can be added to httpd core so that it
> can be enabled just like other modules*, whether or not anyone here
> cares about the implementation details.
>
> *Of course that isn't really true of the popular 2.2.x branch, but I
> don't think it is realistic to hope that mpm-itk would ever make it to
> 2.2.x anyway.

If we can really get mpm-itk compilable out-of-tree without Apache patches,
that would certainly be a better situation than what we have today.
(The situation with 2.2.x will work itself out in time, of course,
as distributions and users slowly migrate to 2.4.x.)

> By the way, did any other httpd-ers have a look at those patches and
> have suggestions for what hooks could be added?

I don't know how many have actually looked at the code in detail; there was
some light review around the time of the initial 2.4.x port, but I generally
do not receive a lot of feedback on the httpd integration itself. I guess
it's not a part that make a lot of people excited.

/* Steinar */
--
Homepage: http://www.sesse.net/


trawick at gmail

Jul 20, 2012, 11:12 AM

Post #13 of 36 (1248 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Fri, Jul 20, 2012 at 1:56 PM, Steinar H. Gunderson
<sesse [at] samfundet> wrote:
> On Fri, Jul 20, 2012 at 01:48:33PM -0400, Jeff Trawick wrote:
>>> Why would you keep mpm-itk separate but mod_privileges not?
>>
>> IMO it is not a very relevant question given the big picture:
>>
>> * Most modules written for httpd are not bundled with the server or
>> otherwise hosted/developed at the ASF.
>> * mod_privileges is for a minority server operating system and is not
>> used extensively even there.
>> * You won't find much rhyme or reason to why some modules are bundled
>> and some are not other than whether or the author has commit access,
>> and even then there isn't much consistency.
>
> I'm not sure if I understand this. Should not the module is considered
> useful be a better criteria than the module is written by someone with
> commit access? And how can the module has a very small user base be an
> argument _for_ keeping it in trunk, and the more popular one out?

I don't think there's much to understand; you can point at the current
slate of included and excluded modules that we ended up with after 15
or so years of development and read from that anything you want (or
read nothing from it, as I suggest).

> If nothing else, should not a module that's patched in by a significant
> fraction be pulled into the main tree, to lighten the burden on distributors?

Distributors can generally take care of themselves. Some active httpd
developers represent distributors of httpd, and they can jump in and
help if they think the technical justification and integration burden
warrant.

>> As far as mpm-itk: A few hooks can be added to httpd core so that it
>> can be enabled just like other modules*, whether or not anyone here
>> cares about the implementation details.
>>
>> *Of course that isn't really true of the popular 2.2.x branch, but I
>> don't think it is realistic to hope that mpm-itk would ever make it to
>> 2.2.x anyway.
>
> If we can really get mpm-itk compilable out-of-tree without Apache patches,
> that would certainly be a better situation than what we have today.
> (The situation with 2.2.x will work itself out in time, of course,
> as distributions and users slowly migrate to 2.4.x.)
>
>> By the way, did any other httpd-ers have a look at those patches and
>> have suggestions for what hooks could be added?
>
> I don't know how many have actually looked at the code in detail; there was
> some light review around the time of the initial 2.4.x port, but I generally
> do not receive a lot of feedback on the httpd integration itself. I guess
> it's not a part that make a lot of people excited.

I'll try to make some progress with API extensions anyway if nobody
speaks up soon.

>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>



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


covener at gmail

Jul 20, 2012, 12:03 PM

Post #14 of 36 (1253 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
> If nothing else, should not a module that's patched in by a significant
> fraction be pulled into the main tree, to lighten the burden on distributors?

Personally, this is not a big consideration in my vote on this project
taking responsibility for a module.


sesse at samfundet

Jul 20, 2012, 3:11 PM

Post #15 of 36 (1247 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 05:26:23PM +0100, Nick Kew wrote:
> How does it protect against such potential attacks as running an
> external program as root through a RewriteMap running earlier
> than the directory walk?

By the way, I actually tried this under prefork. I compiled httpd-2.4.2
with prefork and the following configuration in a vhost:

RewriteEngine on
Rewritemap examplemap prg:/home/sesse/mymapper.pl
RewriteRule /invalid %{examplemap:$1}

and lo and behold, mymapper.pl is started as root. mod_rewrite seems to open
the map programs already when parsing the configuration file, which is before
the MPMs' hooks run (and that's when prefork drops its privileges).

/* Steinar */
--
Homepage: http://www.sesse.net/


sf at sfritsch

Jul 22, 2012, 12:29 PM

Post #16 of 36 (1242 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thursday 19 July 2012, Graham Leggett wrote:
> On 19 Jul 2012, at 18:07, Tim Bannister <isoma [at] jellybaby> wrote:
> > On 19 Jul 2012, at 17:26, Nick Kew wrote:
> >
> >
> >>> 2. Fixes to get Apache to drop the connection if it detects
> >>> (during .htaccess lookup) that it would need to change the
> >>> uid.
> >>
> >>
> >>
> >> Dropping the connection gratuitously breaks HTTP, and so has no
> >> place in httpd (of course, a third-party module sets its own
> >> rules). Would it need a core patch to return an Internal Server
> >> Error (500)?
> >
> >
> >
> > Vanilla httpd does this all the time… after a timed-out
> > keepalive. The client cannot make any assumptions about the
> > configured timeout, and can't tell whether the dropped
> > connection is due to a genuine timeout or a UID mismatch between
> > the previous and current request.
>
> I would hate to have to troubleshoot this - two completely
> independent behaviors, with the same symptom but completely
> different cause.
>
> Nick is right, a 500 is the right thing to do here.

No, mpm itk only closes the connection if a keep-alive request would
need to be processed with a different uid than the previous request on
the same connection. I.e., it cannot happen for the first request on a
connection (which would cause breakage).

But dropping the conn for a keep-alive request is allowed, and there
are other modules that do it in some cases (including mod_proxy and
mpm_event).


sf at sfritsch

Jul 22, 2012, 12:57 PM

Post #17 of 36 (1233 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Friday 20 July 2012, Steinar H. Gunderson wrote:
> On Fri, Jul 20, 2012 at 01:48:33PM -0400, Jeff Trawick wrote:
> >> Why would you keep mpm-itk separate but mod_privileges not?

On reason may be that (at least in theory), mod_privileges is more
secure: Under Solaris you cannot get uid 0 unless you already have all
privileges, so an exploited httpd with mod_privileges does not give
you root. Under Linux however, CAP_SETUID is equivalent to full
unrestricted root, because it allows you to write to root owned files
(like /etc/crontab or /root/.ssh/authorized_keys).

> > IMO it is not a very relevant question given the big picture:
> >
> > * Most modules written for httpd are not bundled with the server
> > or otherwise hosted/developed at the ASF.
> > * mod_privileges is for a minority server operating system and is
> > not used extensively even there.
> > * You won't find much rhyme or reason to why some modules are
> > bundled and some are not other than whether or the author has
> > commit access, and even then there isn't much consistency.
>
> I'm not sure if I understand this. Should not “the module is
> considered useful” be a better criteria than “the module is
> written by someone with commit access”? And how can “the module
> has a very small user base” be an argument _for_ keeping it in
> trunk, and the more popular one out?
>
> If nothing else, should not a module that's patched in by a
> significant fraction be pulled into the main tree, to lighten the
> burden on distributors?

It also a question of the expected maintenance overhead and the
available man-power. For example, according to Debian's popcon,
mod_fcgid has around three times as many users as mpm-itk, but it is
not part of core httpd either. One of the reasons is that not enough
active developers are really interested in mod_fcgid.

> > As far as mpm-itk: A few hooks can be added to httpd core so
> > that it can be enabled just like other modules*, whether or not
> > anyone here cares about the implementation details.
> >
> > *Of course that isn't really true of the popular 2.2.x branch,
> > but I don't think it is realistic to hope that mpm-itk would
> > ever make it to 2.2.x anyway.
>
> If we can really get mpm-itk compilable out-of-tree without Apache
> patches, that would certainly be a better situation than what we
> have today.

Yes, that would be a good thing. It would be even better if it could
work as normal (non-mpm) module together with mpm-prefork. And if it
gets secured to where a code execution exploit does not grant full
root rights, I would probably be in favor of including it with httpd.


sesse at samfundet

Jul 22, 2012, 1:18 PM

Post #18 of 36 (1231 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Sun, Jul 22, 2012 at 09:57:18PM +0200, Stefan Fritsch wrote:
> On reason may be that (at least in theory), mod_privileges is more
> secure: Under Solaris you cannot get uid 0 unless you already have all
> privileges, so an exploited httpd with mod_privileges does not give
> you root. Under Linux however, CAP_SETUID is equivalent to full
> unrestricted root, because it allows you to write to root owned files
> (like /etc/crontab or /root/.ssh/authorized_keys).

It is possible to set prctl(PR_SET_KEEPCAPS, 1) and then setuid() to a
non-root user and still keep the privileges. This would remove the write to
/etc/crontab; I am unsure what happens in practice if the process does
goes back to uid 0 via setuid(), but in Linux 3.5 or newer, we can disallow
that through a seccomp BPF filter. (Arguably this does not help FreeBSD,
Solaris or any other non-Linux OS. Also, Linux 3.5 was only released this
week, and thus needs some more time before it gets into the hands of a
typical server admin.)

> It also a question of the expected maintenance overhead and the
> available man-power. For example, according to Debian's popcon,
> mod_fcgid has around three times as many users as mpm-itk, but it is
> not part of core httpd either. One of the reasons is that not enough
> active developers are really interested in mod_fcgid.

Again, this argument does not really make sense considering the inclusion of
mod_privileges, which surely must have a much smaller user base than mpm-itk.

>> If we can really get mpm-itk compilable out-of-tree without Apache
>> patches, that would certainly be a better situation than what we
>> have today.
> Yes, that would be a good thing. It would be even better if it could
> work as normal (non-mpm) module together with mpm-prefork.

This would probably require some rearchitecting; it's certainly possible
(mod_privileges has already shown that), but it's quite a lot of work,
given that we do expect some cooperation from the MPM currently (e.g. to keep
the scoreboard). What's the primary advantage -- less code duplication?

I think we should try to get mpm-itk working without patching Apache first;
then we can revisit changing it from an MPM into a normal module, if there is
consensus that it would help its inclusion.

/* Steinar */
--
Homepage: http://www.sesse.net/


sf at sfritsch

Jul 22, 2012, 1:54 PM

Post #19 of 36 (1232 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Sunday 22 July 2012, Steinar H. Gunderson wrote:
> On Sun, Jul 22, 2012 at 09:57:18PM +0200, Stefan Fritsch wrote:
> > On reason may be that (at least in theory), mod_privileges is
> > more secure: Under Solaris you cannot get uid 0 unless you
> > already have all privileges, so an exploited httpd with
> > mod_privileges does not give you root. Under Linux however,
> > CAP_SETUID is equivalent to full unrestricted root, because it
> > allows you to write to root owned files (like /etc/crontab or
> > /root/.ssh/authorized_keys).
>
> It is possible to set prctl(PR_SET_KEEPCAPS, 1) and then setuid()
> to a non-root user and still keep the privileges. This would
> remove the write to /etc/crontab; I am unsure what happens in
> practice if the process does goes back to uid 0 via setuid(), but
> in Linux 3.5 or newer, we can disallow that through a seccomp BPF
> filter. (Arguably this does not help FreeBSD, Solaris or any other
> non-Linux OS. Also, Linux 3.5 was only released this week, and
> thus needs some more time before it gets into the hands of a
> typical server admin.)

As long as the process has CAP_SETUID, it can switch back to uid 0 and
write root owned files. But seccomp BPF should be able to fix that.
For FreeBSD, one could use capsicum.

> > It also a question of the expected maintenance overhead and the
> > available man-power. For example, according to Debian's popcon,
> > mod_fcgid has around three times as many users as mpm-itk, but it
> > is not part of core httpd either. One of the reasons is that not
> > enough active developers are really interested in mod_fcgid.
>
> Again, this argument does not really make sense considering the
> inclusion of mod_privileges, which surely must have a much smaller
> user base than mpm-itk.

Then, it seems, Jeff is correct: There is no consistent set of
criteria wether to include or not to include a module. Or maybe the
criteria change over time (mod_privileges has been added 4 years ago).

> > Yes, that would be a good thing. It would be even better if it
> > could work as normal (non-mpm) module together with mpm-prefork.
>
> This would probably require some rearchitecting; it's certainly
> possible (mod_privileges has already shown that), but it's quite a
> lot of work, given that we do expect some cooperation from the MPM
> currently (e.g. to keep the scoreboard). What's the primary
> advantage -- less code duplication?

Yes, that's the primary argument. And maybe being able to use the same
hooks in different interesting ways. From a superficial glance, it
seems that (in addition to the two new hooks already mentioned)
hooking near ap_run_create_connection into mpm-prefork would take care
of most of it. But I could be wrong.

> I think we should try to get mpm-itk working without patching
> Apache first; then we can revisit changing it from an MPM into a
> normal module, if there is consensus that it would help its
> inclusion.

Sure.


sesse at samfundet

Jul 23, 2012, 3:40 AM

Post #20 of 36 (1228 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Sun, Jul 22, 2012 at 09:57:18PM +0200, Stefan Fritsch wrote:
> And if it gets secured to where a code execution exploit does not grant
> full root rights, I would probably be in favor of including it with httpd.

I took a look using seccomp for this, and it would seem it is actually
rather hard; you can limit setuid() and setgid() easily enough to a range
(so that you'd typically exclude root, daemon and other low-uid stuff),
but setgroups() takes in a pointer of supplementary gids to add. I can't find
any good ways of looking into that list, so it would seem a rogue process
could arbitrarily add any gid (like, 0) to its list.

So it seems to be hard to properly restrict gid, but maybe restricting uid
would already give a significant win?

/* Steinar */
--
Homepage: http://www.sesse.net/


jorton at redhat

Jul 23, 2012, 7:39 AM

Post #21 of 36 (1235 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 04:17:44PM +0200, Steinar H. Gunderson wrote:
> Furthermore, Fedora has recently accepted the mpm-itk patch into their Apache
> packages.

For the record, that is not accurate. The Fedora httpd package does not
contain the mpm-itk patch, I have repeatedly refused to add it since it
makes changes to core httpd which need to go through upstream review.
Using such arguments to "bully" upstream into taking patches is not a
great way to build goodwill, IMO.

Somebody has apparently added a completely separate httpd-itk package
which does include the patch, which is totally dumb IMO, but we (Fedora)
apparently don't legislate against that in the review process.

Regards, Joe


trawick at gmail

Aug 1, 2012, 10:58 AM

Post #22 of 36 (1130 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Thu, Jul 19, 2012 at 11:38 AM, Steinar H. Gunderson
<sgunderson [at] bigfoot> wrote:
> On Thu, Jul 19, 2012 at 11:27:04AM -0400, Jeff Trawick wrote:
>> What changes are needed to httpd trunk so that you can build mpm-itk
>> with apxs and enable it via LoadModule, such that mpm-itk is fully
>> functional? As I'm sure you're aware, prefork, worker, and event are
>> all untied from core enough to support that in httpd >= 2.4.
>
> We'd need:
>
> 1. A hook right after merging the perdir config.
> 2. Fixes to get Apache to drop the connection if it detects
> (during .htaccess lookup) that it would need to change the uid.
>
> Both patches are simple, although for #2 to be truly generic (ie. be usable
> by mod_privileges as well) we'd need some sort of signalling mechanism saying
> we have switched uids and cannot switch back, which then both
> mod_privileges (in secure mode) and mpm-itk could set.
>
> I've attached the current versions of both patches from my current Apache 2.4
> patch set; you can see the ap_running_under_mpm_itk variable which would
> probably need to be replaced by ap_mpm_query() or similar.
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>

Your post-perdir-config patch has been committed to trunk with r1368121.

(http://svn.apache.org/viewvc?view=revision&revision=r1368121)

Attached is a patch to trunk that allows you to hook in to the stat
calls from directory walk. Call apr_stat() like core_dirwalk_stat()
but check for APR_STATUS_IS_EACCES(rv) and decide whether to run
lingering close and exit. Let us know how that goes.

You still need the parse-htaccess patch for now.

--
Born in Roswell... married an alien...
http://emptyhammock.com/
Attachments: dirwalk_stat.txt (4.10 KB)


sgunderson at bigfoot

Aug 5, 2012, 8:00 AM

Post #23 of 36 (1124 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Wed, Aug 01, 2012 at 01:58:16PM -0400, Jeff Trawick wrote:
> Your post-perdir-config patch has been committed to trunk with r1368121.

Thanks!

> Attached is a patch to trunk that allows you to hook in to the stat
> calls from directory walk. Call apr_stat() like core_dirwalk_stat()
> but check for APR_STATUS_IS_EACCES(rv) and decide whether to run
> lingering close and exit. Let us know how that goes.
>
> You still need the parse-htaccess patch for now.

I backported this to 2.4.2, and changed mpm-itk to hook into that function
with the following hook:

static apr_status_t itk_dirwalk_stat(apr_finfo_t *finfo, request_rec *r,
apr_int32_t wanted)
{
apr_status_t status = apr_stat(finfo, r->filename, wanted, r->pool);
if (ap_has_irreversibly_setuid && APR_STATUS_IS_EACCES(status)) {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, status, r,
"Couldn't read %s, closing connection.",
r->filename);
ap_lingering_close(r->connection);
clean_child_exit(0);
}
return status;
}

Seems to work great, from my limited testing. As an extra bonus, I can easily
call clean_child_exit() (which runs more cleanup hooks) instead of exit(),
since this is in the MPM's own .c file.

/* Steinar */
--
Homepage: http://www.sesse.net/


trawick at gmail

Aug 5, 2012, 8:05 AM

Post #24 of 36 (1116 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Sun, Aug 5, 2012 at 11:00 AM, Steinar H. Gunderson
<sgunderson [at] bigfoot> wrote:
> On Wed, Aug 01, 2012 at 01:58:16PM -0400, Jeff Trawick wrote:
>> Your post-perdir-config patch has been committed to trunk with r1368121.
>
> Thanks!
>
>> Attached is a patch to trunk that allows you to hook in to the stat
>> calls from directory walk. Call apr_stat() like core_dirwalk_stat()
>> but check for APR_STATUS_IS_EACCES(rv) and decide whether to run
>> lingering close and exit. Let us know how that goes.
>>
>> You still need the parse-htaccess patch for now.
>
> I backported this to 2.4.2, and changed mpm-itk to hook into that function
> with the following hook:
>
> static apr_status_t itk_dirwalk_stat(apr_finfo_t *finfo, request_rec *r,
> apr_int32_t wanted)
> {
> apr_status_t status = apr_stat(finfo, r->filename, wanted, r->pool);
> if (ap_has_irreversibly_setuid && APR_STATUS_IS_EACCES(status)) {
> ap_log_rerror(APLOG_MARK, APLOG_WARNING, status, r,
> "Couldn't read %s, closing connection.",
> r->filename);
> ap_lingering_close(r->connection);
> clean_child_exit(0);
> }
> return status;
> }
>
> Seems to work great, from my limited testing. As an extra bonus, I can easily
> call clean_child_exit() (which runs more cleanup hooks) instead of exit(),
> since this is in the MPM's own .c file.

Great! I'll do something about the remaining patch "before long".

>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/



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


sgunderson at bigfoot

Aug 5, 2012, 8:32 AM

Post #25 of 36 (1102 views)
Permalink
Re: mpm-itk and upstream Apache, once again [In reply to]
On Sun, Aug 05, 2012 at 11:05:59AM -0400, Jeff Trawick wrote:
> Great! I'll do something about the remaining patch "before long".

When the time comes, do we have any hopes of getting this back from trunk to
2.4, or would it need to wait for 2.6/3.0?

FWIW, the mpm-itk security hardening that was discussed (running with uid != 0,
and limiting setuid/setgid ranges through seccomp) is starting to come quite
nicely along, although the problem of initgroups() remains (a rogue process
with CAP_SETGID can add any supplementary group it pleases, and seccomp is
unable to check it), and there's been very limited user testing so far.
I guess we can't get fully down to the level of prefork, but it can get
pretty close.

/* Steinar */
--
Homepage: http://www.sesse.net/

First page Previous page 1 2 Next page Last page  View All 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.