Re: mod_proxy chaining with a .pac file
On Wed, 2008-01-23 at 22:19 +, Giovanni Donelli wrote: Are you talking about a JS lib or a code that does what I need, support for .pac proxy chaning? The later. Sorry, that library wasn't linked to from your original post, but it can be found on the wikipedia page. Here's a direct link: http://code.google.com/p/pacparser/ From browsing the documentation it looks like it does all you need. HTH RalfD As with regards with JS I was going to use the WebKit's JavaScriptCore. There _IS_ a library (C and python(?) interface) - downloadable from the google code link posted in the first message ... trivial to link into an Apache module. AFAIK it uses the mozilla JS code. Cheers, RalfD Joe
Re: mod_proxy chaining with a .pac file
Great. Thanks! This solve 50% of the problem. The other problem is to actually plug this into mod_proxy. Is there a hook a can use to override the connection to the remote server? What do you guys suggest? thanks! On Jan 24, 2008 12:50 PM, Ralf Mattes [EMAIL PROTECTED] wrote: On Wed, 2008-01-23 at 22:19 +, Giovanni Donelli wrote: Are you talking about a JS lib or a code that does what I need, support for .pac proxy chaning? The later. Sorry, that library wasn't linked to from your original post, but it can be found on the wikipedia page. Here's a direct link: http://code.google.com/p/pacparser/ From browsing the documentation it looks like it does all you need. HTH RalfD As with regards with JS I was going to use the WebKit's JavaScriptCore. There _IS_ a library (C and python(?) interface) - downloadable from the google code link posted in the first message ... trivial to link into an Apache module. AFAIK it uses the mozilla JS code. Cheers, RalfD Joe
Re: What am I doing wrong - site gen?
On Wed, Jan 23, 2008 at 03:53:38PM -0800, William Rowe wrote: security/vulnerabilities-oval.xml I'm ending up with deltas such as these... -httpd_state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; id=oval:org.apache.httpd:ste:131 version=1 comment=the version of httpd is 1.3.1 -version operation=equals datatype=version1.3.1/version +httpd_state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; id=oval:org.apache.httpd:ste:131 version=1 comment=the version of httpd is 1.3.1 +version xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; operation=equals datatype=version1.3.1/version /httpd_state What component are we missing in site/lib/ or should I have locally updated? The fragment in the namespace URI is being dropped, odd. It works fine for me. Does the patch below make any difference? Index: xdocs/stylesheets/httpd-oval.xsl === --- xdocs/stylesheets/httpd-oval.xsl(revision 612495) +++ xdocs/stylesheets/httpd-oval.xsl(working copy) @@ -357,14 +357,14 @@ !-- Print out the actual state element. -- -xsl:element name=httpd_state namespace=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; +httpd_state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; xsl:attribute name=idxsl:value-of select=$state_id//xsl:attribute xsl:attribute name=version1/xsl:attribute xsl:attribute name=commentxsl:value-of select=$state_comment//xsl:attribute version datatype=version operation=equals xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; xsl:value-of select=@version/ /version -/xsl:element +/httpd_state /xsl:template !-- -- !-- --
High security
Hello, As some may now, ModSecurity adds a very easy and effective way to put Apache in jail, but chrooting the process after its initialisation, thus putting all listening processes in jail. You specify one directive, and the only thing you have to put in the jail is your htdocs and logs directories; all other files (conf, modules, httpd, libraries, etc.) are outside of the jail. This is really top security - it's almost impossible to find something to hack. Unfortunately, the only thing that does not work is a graceful restart, as the process has no more access to all normal files. Couldn't it be possible to separate the main process in 2 - one real master performing the start/stop/restart, and one almost main chrooted process which would spawn the listening children processes ? The chrooted process could be implemented in the core, or it could be left to ModSecurity. That would be the top security, much more secure than any solution based on IIS for instance. Do you think this could be envisioned ? Thanks, Nick
Re: High security
On Thu, Jan 24, 2008 at 01:10:23PM +0100, Nick Gearls wrote: You specify one directive, and the only thing you have to put in the jail is your htdocs and logs directories; all other files (conf, modules, httpd, libraries, etc.) are outside of the jail. This is really top security - it's almost impossible to find something to hack. Well don't kid yourself, it makes privilege escalation by certain routes much harder, but it's not even clost to almost impossible. There are many forms of IPC available between the children and the root-level Apache process anyway, and if you manage to exploit that it's game over anyway (including breaking out of the jail). Unfortunately, the only thing that does not work is a graceful restart, as the process has no more access to all normal files. Couldn't it be possible to separate the main process in 2 - one real master performing the start/stop/restart, and one almost main chrooted process which would spawn the listening children processes ? The chrooted process could be implemented in the core, or it could be left to ModSecurity. It'd be a new MPM. That would be the top security, much more secure than any solution based on IIS for instance. Do you think this could be envisioned ? Can't see it happening personally. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
RE: High security
-Original Message-
From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 24. Januar 2008 13:16
To: dev@httpd.apache.org
Subject: Re: High security
On Thu, Jan 24, 2008 at 01:10:23PM +0100, Nick Gearls wrote:
You specify one directive, and the only thing you have to
put in the
jail is your htdocs and logs directories; all other files (conf,
modules, httpd, libraries, etc.) are outside of the jail.
This is really
top security - it's almost impossible to find something to hack.
Well don't kid yourself, it makes privilege escalation by
certain routes
much harder, but it's not even clost to almost impossible. There are
many forms of IPC available between the children and the root-level
Apache process anyway, and if you manage to exploit that it's
game over
anyway (including breaking out of the jail).
Yep. chroot was never designed to be a security feature. It can make
things more difficult to leave a jailed area.
See also http://kerneltrap.org/Linux/Abusing_chroot
or have a look at
#include stdio.h
#include unistd.h
#include sys/stat.h
#include sys/types.h
int main(int argc, char *argv[])
{
FILE *file;
chroot(/tmp/zw/blah1);
chdir(/);
file = fopen(blah1, w);
fprintf(file, Hello\n);
fclose(file);
mkdir(foo, 493);
chroot(foo);
chdir(..);
chdir(blah2);
file = fopen(blah2, w);
fprintf(file, Hello\n);
fclose(file);
return 0;
}
which allows you to escape the chroot of /tmp/zw/blah1 if
you are still root at the point of time mkdir is executed
and write a file to /tmp/zw/blah2
Regards
Rüdiger
Re: svn commit: r614605 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
On 1/23/2008 at 7:25 PM, in message [EMAIL PROTECTED], Paul J.
Reder [EMAIL PROTECTED] wrote:
Ruediger Pluem wrote:
On 01/23/2008 07:14 PM, [EMAIL PROTECTED] wrote:
Author: rederpj
Date: Wed Jan 23 10:14:41 2008
New Revision: 614605
URL: http://svn.apache.org/viewvc?rev=614605view=rev
Log:
This adds Apache support (taking advantage of the new APR capability)
for ldap rebind callback while chasing referrals. This allows direct
searches on LDAP servers (in particular MS Active Directory 2003+)
using referrals without the use of the global catalog.
This addresses PRs 26538, 40268, and 42557
@@ -2614,6 +2710,15 @@
Specify the LDAP socket connection timeout in seconds
(default: 10)),
+AP_INIT_FLAG(LDAPReferrals, util_ldap_set_chase_referrals,
+ NULL, OR_AUTHCFG,
+ Choose whether referrals are chased ['ON'|'OFF'].
Default ON'),
+
+AP_INIT_TAKE1(LDAPReferralHopLimit,
util_ldap_set_referral_hop_limit,
+ NULL, OR_AUTHCFG,
+ Limit the number of referral hops that LDAP can
follow.
+ (Integer value, default=5)),
+
{NULL}
};
@@ -2638,7 +2743,7 @@
module AP_MODULE_DECLARE_DATA ldap_module = {
STANDARD20_MODULE_STUFF,
- NULL,/* create dir config */
+ util_ldap_create_dir_config, /* create dir config */
NULL,/* merge dir config */
Why no merge dir config? How do you inherit your settings in this case?
Now that you ask that question it makes me realize that the better question
is
probably Should the directives be directory scoped or server scoped? The
rest
of the util_ldap directives are all server scoped. Is there any compelling
reason
that the referral directives would need to be alterable on a
directory-by-directory
(or htaccess) basis or should it be turned on/off and limited on a
server-wide scope?
I wish I had a better memory, but I vaguely recall going down this path once
before between server-merge and dir-merge (mailing list archives might remember
better than I do) . I know that when it comes to anything SSL related, not all
LDAP SDKs can handle per-directory options. Novell LDAP SDK being one of them.
So when it comes to setting options on a per-directory basis, it might get a
little tricky depending on the LDAP SDK that is being used.
Brad
Re: High security
Yes, chroot could potentially be escaped.
Although, if you chroot the main process, then you spawn child processes
under another userid, like in standard Apache config under Unix, I
expect it to be really very difficult to escape if
1. you are not root
2. if the only files available are log files and htdocs files (even no
HTML files in case of a reverse proxy
Obviously, we could imagine a vulnerability (like a buffer overrun) in
the child Apache process that would send a signal to the main process to
use a second vulnerability, but I really find that chrooting Apache
provides a very good defense.
Now, my main question is do I add all executables, load modules,
libraries, etc. ?. I need to if I want graceful restart (and you
usually need that in a real production environment). This definitely
higher the risk, so why not trying to improve this ?
Defense in depth is a golden rule in security, no ? So, even if chroot
may not be totally bullet proof, it should, imho, be used. And, if we
want Apache to be as secure as possible, it should be as
chroot-friendly as possible.
I hope this could convince some key developers ...
Nick
Plüm wrote:
-Original Message-
From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 24. Januar 2008 13:16
To: dev@httpd.apache.org
Subject: Re: High security
On Thu, Jan 24, 2008 at 01:10:23PM +0100, Nick Gearls wrote:
You specify one directive, and the only thing you have to
put in the
jail is your htdocs and logs directories; all other files (conf,
modules, httpd, libraries, etc.) are outside of the jail.
This is really
top security - it's almost impossible to find something to hack.
Well don't kid yourself, it makes privilege escalation by
certain routes
much harder, but it's not even clost to almost impossible. There are
many forms of IPC available between the children and the root-level
Apache process anyway, and if you manage to exploit that it's
game over
anyway (including breaking out of the jail).
Yep. chroot was never designed to be a security feature. It can make
things more difficult to leave a jailed area.
See also http://kerneltrap.org/Linux/Abusing_chroot
or have a look at
#include stdio.h
#include unistd.h
#include sys/stat.h
#include sys/types.h
int main(int argc, char *argv[])
{
FILE *file;
chroot(/tmp/zw/blah1);
chdir(/);
file = fopen(blah1, w);
fprintf(file, Hello\n);
fclose(file);
mkdir(foo, 493);
chroot(foo);
chdir(..);
chdir(blah2);
file = fopen(blah2, w);
fprintf(file, Hello\n);
fclose(file);
return 0;
}
which allows you to escape the chroot of /tmp/zw/blah1 if
you are still root at the point of time mkdir is executed
and write a file to /tmp/zw/blah2
Regards
Rüdiger
Certificate validation problems trapping - bug #35083
Hello, The proposed patch generalizes a mechanism that currently exist, but is incomplete. It now allows to accept all SSL connections that fail for any reason related to certificate verification or validation. Could this be included in next release ? This has a huge impact on the user, as it is possible to give a meaningful error message in case of a problem (like your certificate is revoked), instead of a network error at SSL level. The patch is quite simple, and it is used in several major Governmental servers in Belgium, so we shouldn't expect problems. Regards, Nick
Re: What am I doing wrong - site gen?
Joe Orton wrote: On Wed, Jan 23, 2008 at 03:53:38PM -0800, William Rowe wrote: security/vulnerabilities-oval.xml I'm ending up with deltas such as these... -httpd_state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; id=oval:org.apache.httpd:ste:131 version=1 comment=the version of httpd is 1.3.1 -version operation=equals datatype=version1.3.1/version +httpd_state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; id=oval:org.apache.httpd:ste:131 version=1 comment=the version of httpd is 1.3.1 +version xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; operation=equals datatype=version1.3.1/version /httpd_state What component are we missing in site/lib/ or should I have locally updated? The fragment in the namespace URI is being dropped, odd. It works fine for me. Does the patch below make any difference? Index: xdocs/stylesheets/httpd-oval.xsl === --- xdocs/stylesheets/httpd-oval.xsl(revision 612495) +++ xdocs/stylesheets/httpd-oval.xsl(working copy) @@ -357,14 +357,14 @@ !-- Print out the actual state element. -- -xsl:element name=httpd_state namespace=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; +httpd_state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; xsl:attribute name=idxsl:value-of select=$state_id//xsl:attribute xsl:attribute name=version1/xsl:attribute xsl:attribute name=commentxsl:value-of select=$state_comment//xsl:attribute version datatype=version operation=equals xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; xsl:value-of select=@version/ /version -/xsl:element +/httpd_state /xsl:template !-- -- !-- -- It creates a 100% delta to the file... the pattern on this box looks like Index: docs/security/vulnerabilities-oval.xml === --- docs/security/vulnerabilities-oval.xml (revision 614738) +++ docs/security/vulnerabilities-oval.xml (working copy) @@ -719,7 +719,7 @@ /description apache_httpd_repository public20060508/public -reported/reported +reported/ released20060501/released severity level=3moderate/severity /apache_httpd_repository @@ -2775,225 +2775,225 @@ /definition /definitions tests -httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; i d=oval:org.apache.httpd:tst:226 version=1 comment=the version of httpd is 2 .2.6 check=at least one -object object_ref=oval:org.apache.httpd:obj:1/ -state state_ref=oval:org.apache.httpd:ste:226/ +httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; id=oval :org.apache.httpd:tst:226 version=1 comment=the version of httpd is 2.2.6 c heck=at least one +object xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; objec t_ref=oval:org.apache.httpd:obj:1/ +state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; state_ref=ov al:org.apache.httpd:ste:226/ /httpd_test -httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; i d=oval:org.apache.httpd:tst:225 version=1 comment=the version of httpd is 2 .2.5 check=at least one -object object_ref=oval:org.apache.httpd:obj:1/ -state state_ref=oval:org.apache.httpd:ste:225/ +httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; id=oval :org.apache.httpd:tst:225 version=1 comment=the version of httpd is 2.2.5 c heck=at least one +object xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; objec t_ref=oval:org.apache.httpd:obj:1/ +state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; state_ref=ov al:org.apache.httpd:ste:225/ /httpd_test -httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; i d=oval:org.apache.httpd:tst:224 version=1 comment=the version of httpd is 2 .2.4 check=at least one -object object_ref=oval:org.apache.httpd:obj:1/ -state state_ref=oval:org.apache.httpd:ste:224/ +httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; id=oval :org.apache.httpd:tst:224 version=1 comment=the version of httpd is 2.2.4 c heck=at least one +object xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; objec t_ref=oval:org.apache.httpd:obj:1/ +state xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5; state_ref=ov al:org.apache.httpd:ste:224/ /httpd_test -httpd_test xmlns=http://oval.mitre.org/XMLSchema/oval-definitions-5#apache; i d=oval:org.apache.httpd:tst:223 version=1 comment=the version of httpd is 2 .2.3 check=at least one -object object_ref=oval:org.apache.httpd:obj:1/ -state state_ref=oval:org.apache.httpd:ste:223/ +httpd_test
Re: Is async the answer?
We were using normal worker MPM with keepalives for this test. The current stable event would have helped with idle keepalive threads, but the system didn't seem to care. But when using mod_php, worker is not recommended, right? I doubt prefork scales as well as worker. Working on making a FastCGI based setup the recommended approach instead of mod_php is probably more important then async. Actually, it's a prerequisite. Having 30k threads still seems like a waste of resource to me though. What about a hybrid approach? Async for network IO and other stuff that doesn't require sync calls, worker threads for other parts? Olaf
Re: High security
On 01/24/2008 04:55 PM, Nick Gearls wrote: Yes, chroot could potentially be escaped. Although, if you chroot the main process, then you spawn child processes under another userid, like in standard Apache config under Unix, I expect it to be really very difficult to escape if 1. you are not root 2. if the only files available are log files and htdocs files (even no HTML files in case of a reverse proxy Obviously, we could imagine a vulnerability (like a buffer overrun) in the child Apache process that would send a signal to the main process to use a second vulnerability, but I really find that chrooting Apache provides a very good defense. It is some kind of defense, but as stated chroot is not really a security tool (see also http://it.slashdot.org/article.pl?sid=07/09/27/2256235). Nevertheless, back to your problem. I think there is no gain at all doing a chroot in the httpd main process which keeps running as root. So IMHO mod_security is doing the chroot too early by doing it in the post config hook. I admit that I do not see any other hook at the moment to do this. But there is a patch in trunk that does chroot only for the child processes, just before the userid is switched. I haven't tested this so far, but this should work with graceful restarts. Plus: You do not need to keep your logs in the chroot jail as the logfiles are opened by the main process. Patch: http://svn.apache.org/viewvc?view=revrevision=611483 PR: http://issues.apache.org/bugzilla/show_bug.cgi?id=43596 Regards Rüdiger
Re: svn commit: r614605 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
The referral code is enabled via set_option calls and is currently processed in relation to a newly created ldap connection. Any further directory related processing would have to support changing the options later, or provide extra criteria when selecting a connection to use. But I agree that, logically, it should be directory scoped. I'm committing the doc now (directory scoped, to match the code I committed) and I'll look at making sure the processing addresses that (via merge, etc). Graham Leggett wrote: Paul J. Reder wrote: Now that you ask that question it makes me realize that the better question is probably Should the directives be directory scoped or server scoped? The rest of the util_ldap directives are all server scoped. The cache related ones are all server scoped, as the cache is server wide. The SSL related ones are directory and/or server scoped, and it depends on the underlying toolkit as to whether directory scope works at all. Don't fall into the trap of thinking all directives have to be handled the same way. My gut feel is that the referral processing should be directory scoped, there is no guarantee that the server will only ever connect to one type of LDAP server at a time, and the admin may want different processing depending on the application. Regards, Graham -- -- Paul J. Reder --- The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure. -- Albert Einstein
Re: svn commit: r614605 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
Paul J. Reder wrote: Now that you ask that question it makes me realize that the better question is probably Should the directives be directory scoped or server scoped? The rest of the util_ldap directives are all server scoped. The cache related ones are all server scoped, as the cache is server wide. The SSL related ones are directory and/or server scoped, and it depends on the underlying toolkit as to whether directory scope works at all. Don't fall into the trap of thinking all directives have to be handled the same way. My gut feel is that the referral processing should be directory scoped, there is no guarantee that the server will only ever connect to one type of LDAP server at a time, and the admin may want different processing depending on the application. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
