Re: High security
I don't think this should be a discussion of whether chroot is worth using as a security measure. IMHO it should be about allowing Apache users to make a choice whether they will use chroot in this way or not. I am usually an advocate for user choice. For example, I am well aware of the various disadvantages of chroot but I still find some cases where it is useful. In particular, it is very good in preventing (or limiting damage from) automated attacks. It is also very good in significantly raising the effort required to compromise a server after a successful compromise of the web server installation running on it (e.g. through a badly written web application). For the record, I have regretted including the chroot feature in ModSecurity many times over. Not because of the feature itself (which -- I still think -- is very useful when the circumstances are right) but because of the support I was required to provide on the mailing list over the years. To troubleshoot chroot issues requires a very good understanding of how things work and takes a lot of time. Subtle problems may arise with modules that are not expecting to be cut-off from the filesystem half-way through, or with modules that fork at startup. With this in mind, I have always felt the reluctance of the Apache developers to include support for chroot has more to do with these support issues rather than with any technical reasons. A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. On Jan 24, 2008 8:33 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: 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 -- Ivan Ristic
Re: PCRE in Apache?
On Jan 25, 2008 5:28 PM, Chris H. [EMAIL PROTECTED] wrote: Greetings all, I'm toying with the idea of using PCRE in Apache 1.3. I see already that there is support for REGEX in the Configuration.tmpl that permits a choice of bundled or system (if available). But was wondering how hard, or if even reasonable to consider adding the same option to use System PCRE (if available) option. And if so, would it be better in the server, or better as a module. I see also that Apache 2+ has this already. I would greatly appreciate any thoughts/feedback/pointers regarding this. Thank you for all your time and consideration in this matter. Use PCRE to do what? Regular expressions are used for many different purposes in apache. But in general, this sounds like it would be way more difficult that just upgrading to a remotely recent version. Joshua.
Re: My hacked mod_xsendfile
* Akins, Brian wrote:
On 1/25/08 3:51 PM, André Malo [EMAIL PROTECTED] wrote:
I don't recommend doing that as it contains a race condition (the file
might be changed in the meantime).
That race is in the default_handler as well, isn't it?
Yes. IIRC there's already a bug report for it.
(That's one of the reasons I like my approach, we just rely on the
features/bugs of the core. Fix/enhance that and everyone benefits. )
Huh? I don't see why we should dup the bug.
By backend I meant here the script providing
the x-sendfile header. That's the only place knowing the behaviour of
the file exactly.
In theory, if backend gives us an x-sendfile, it shouldn't touch it.
Especially if it's a x-sendfile-temp (lighttpd calls this something
strange).
Yes, if it's temp you're right. In the other case there's no guarantee given
to the webserver. X-Sendfile should just take the file and apply the rest
of the headers sent by the backend. Everything doing else lessens its
usefulness.
nd
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://www.perlig.de/ #
Re: My hacked mod_xsendfile
On 1/25/08 3:51 PM, André Malo [EMAIL PROTECTED] wrote: I don't recommend doing that as it contains a race condition (the file might be changed in the meantime). That race is in the default_handler as well, isn't it? It creates a file bucket based on the size of an earlier stat. So, we are setting the content length to what the core handler thinks it is anyway. The bucket is that long. From default_handler: ap_set_content_length(r, r-finfo.size); e = apr_bucket_file_create(fd, 0, (apr_size_t)r-finfo.size, r-pool, c-bucket_alloc); The finfo here is from map_to_storage (directory_walk??) which happened before... In theory to avoid this, we could get_file_info on the open handle. That would need to be changed in default_handler. (That's one of the reasons I like my approach, we just rely on the features/bugs of the core. Fix/enhance that and everyone benefits. ) By backend I meant here the script providing the x-sendfile header. That's the only place knowing the behaviour of the file exactly. In theory, if backend gives us an x-sendfile, it shouldn't touch it. Especially if it's a x-sendfile-temp (lighttpd calls this something strange). -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: High security
On Fri 25 Jan 2008, Nick Kew wrote: A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) Sometimes I have missed a ChildPrivilegedInit hook that is run between fork() and dropping privileges in the worker. That would be the right place to chroot() I think. Torsten
Re: My hacked mod_xsendfile
* Akins, Brian wrote: On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote: If it should not be chunked, the backend simply has to provide a content-length along with the x-sendfile header. Okay, I add ap_set_content_length(r, sub-finfo.size) and that fixes it and does not chunk. I don't recommend doing that as it contains a race condition (the file might be changed in the meantime). By backend I meant here the script providing the x-sendfile header. That's the only place knowing the behaviour of the file exactly. If you want it there nevertheless I'd make it configurable. nd -- print Just Another Perl Hacker; # André Malo, http://www.perlig.de/ #
Re: My hacked mod_xsendfile
On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote: If it should not be chunked, the backend simply has to provide a content-length along with the x-sendfile header. Okay, I add ap_set_content_length(r, sub-finfo.size) and that fixes it and does not chunk. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: My hacked mod_xsendfile
On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote: I'm not sure if a filter is semantically the right place. IMHO that smells a bit problematic. It might be better to I'd rather hack that into a function similar to ap_internal_redirect and let it call explicitly. That way you'd need to hack a recognition per backend (but the code is mostly there anyway), on the other hand you could enable and disable it per backend. A filter was just convenient. It needs to be generic as possible so that, a) people will use it, b) noone has to edit their backend much to support it. X-sendfile is already in the wild and supported by a number of backends. I don't have strong feeling as to how it is implemented within httpd, but the subrequest gives a lot of flexibility to it, like using deflate, running SSI on php output, etc. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: My hacked mod_xsendfile
* Akins, Brian wrote: I started to play with xsendfile more. I noticed the mod_xsendfile floating around tried to basically replace what the default handler does very well. Basically, my version does a subrequest for the file. This allows things like Deny from all, etc, to work. This should be more secure, ie, if you set your deny's correctly, you can't X-Sendfile: /etc/passwd. All in all, it seems more httpd-like, to me. It is very rough. I do not understand brigades enough to know why it is chunking every reply in my tests. I have tested with just a normal cgi setting the header. Not well tested. I'd like to see us work toward getting X-sendfile into the normal httpd distribution (along with mod_fcgid...) Interesting. I wrote something similar a time ago for mod_proxy_scgi, also aimed to be extracted into the core. And hey, it's nearly the same stuff we're doing there, so it can't be that wrong :-) So +1 to have something in the core. http://people.apache.org/~nd/mod_proxy_scgi/mod_proxy_scgi.c The chunked problem is present there, too, but I solved it by ignoring it (you might search for Content-Length for more comments). If it should not be chunked, the backend simply has to provide a content-length along with the x-sendfile header. I'm split: I'm not sure if a filter is semantically the right place. IMHO that smells a bit problematic. It might be better to I'd rather hack that into a function similar to ap_internal_redirect and let it call explicitly. That way you'd need to hack a recognition per backend (but the code is mostly there anyway), on the other hand you could enable and disable it per backend. I like the idea of having its own module. Opinions highly welcome. nd -- [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet? DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da so reinpacken und dann absolut positionieren ... -- Florian Hartig und Lars Kasper in dciwam
Re: Is async the answer?
On 1/24/08 3:14 PM, Olaf van der Spek [EMAIL PROTECTED] wrote: 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. Fastcgi is the recommended way of using php and httpd 2, AFAIK. Isn't it??? Having 30k threads still seems like a waste of resource to me though. Not if system is handling the load very well and needs 30k threads. My point was that 30k threads did not seem to be a waste of resources. I doubt an async server would have used a significantly lower amount of resources because worker did not use a significant amount of resources. What about a hybrid approach? Async for network IO and other stuff that doesn't require sync calls, worker threads for other parts? That's kind of what I was thinking after Apachecon US this year. I won't speak for others, but it seemed reasonable to most. However, after doing several real world tests, I just don't honestly see that async will be a huge improvement. Please prove me wrong with real world results. I'd be more than happy to be wrong on this, really. To be honest, I don't have strong feelings either way. I was surprised by my results. I, now, think that completely rewriting the core to be async *may be* a waste of resources. If it fits nicely into some ideas on reengineering buckets and brigades (ala serf stuff), and does not actually decrease overall performance, then by all means do it. Remember, I'm partially playing devil's advocate as well... -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: High security
On Fri, 25 Jan 2008 11:31:32 + Ivan Ristic [EMAIL PROTECTED] wrote: I don't think this should be a discussion of whether chroot is worth using as a security measure. IMHO it should be about allowing Apache users to make a choice whether they will use chroot in this way or not. +1. For the record, I have regretted including the chroot feature in ModSecurity many times over. Not because of the feature itself (which -- I still think -- is very useful when the circumstances are right) but because of the support I was required to provide on the mailing list over the years. To troubleshoot chroot issues requires a very good understanding of how things work and takes a lot of time. Subtle problems may arise with modules that are not expecting to be cut-off from the filesystem half-way through, or with modules that fork at startup. Thanks for the insight! Chroot problems are indeed a support issue (though still a fairly infrequent one) in apache's own support fora. I guess you've relieved us of some part (maybe most) of that burden. With this in mind, I have always felt the reluctance of the Apache developers to include support for chroot has more to do with these support issues rather than with any technical reasons. Still more likely: lack of round tuits. Builtin support could still happen. In fact I recently committed a patch to /trunk/. A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. Can we expect your contributions to the apache core code in the not-too-distant? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
PCRE in Apache?
Greetings all, I'm toying with the idea of using PCRE in Apache 1.3. I see already that there is support for REGEX in the Configuration.tmpl that permits a choice of bundled or system (if available). But was wondering how hard, or if even reasonable to consider adding the same option to use System PCRE (if available) option. And if so, would it be better in the server, or better as a module. I see also that Apache 2+ has this already. I would greatly appreciate any thoughts/feedback/pointers regarding this. Thank you for all your time and consideration in this matter. --Chris H -- panic: kernel trap (ignored)
My hacked mod_xsendfile
I started to play with xsendfile more. I noticed the mod_xsendfile floating around tried to basically replace what the default handler does very well. Basically, my version does a subrequest for the file. This allows things like Deny from all, etc, to work. This should be more secure, ie, if you set your deny's correctly, you can't X-Sendfile: /etc/passwd. All in all, it seems more httpd-like, to me. It is very rough. I do not understand brigades enough to know why it is chunking every reply in my tests. I have tested with just a normal cgi setting the header. Not well tested. I'd like to see us work toward getting X-sendfile into the normal httpd distribution (along with mod_fcgid...) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies mod_xsendfile.c Description: Binary data
