Re: modperl security model question
Hmm... There might be another solution, but it's probably a bit dangerous - and in any case, one of the more experianced mod_perl people would have to confirm that it works as expected... But it would seem to me that if you can figure out at an early enough stage who you want to run the process as, you could set Apache to run as root:root and then use a ChildInitHandler (or any early stage handler) to do a setuid and setgid. Since perl is part of the child process, this should change the uid & gid of the entire process. This would seem slightly better then the below alternative as you can set MaxRequestsPerChild to 1 and just have one parent process spawning children with different uid/gids, instead of having to start up an entire server for each uid/gid pair... Of course, there's the security problem of everything that happens in the child until it gets to the setuid AND it's very important to make sure that there's a default uid/gid pair for the process to put on to prevent any sort of bypass. I don't know that I'd pick this solution without mulling it over for a few days, but maybe people on the list can think up some of the pro's and con's for me :) Issac (PS. Yes I know it's a dangerous approach, so you don't all have to personally bash me over the head with it ;-) ) Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B - Original Message - From: "sterling" <[EMAIL PROTECTED]> To: "Thomas K. Burkholder" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, April 15, 2001 6:06 PM Subject: Re: modperl security model question > On Sun, 15 Apr 2001, Thomas K. Burkholder wrote: > > > Thanks again for the help - I have another one- > > > > My application consists of perl modules with file permissions set only > > to a particular user 'burkhold'. The database password is kept in > > plaintext in one of those modules. I use the User: and Group: > > directives in access.conf to cause the uid of the spawned httpd process > > to have permission to execute the code. It works fine, except that it > > seems I can't embed 'User: burkhold' inside a directive, so > > all requests have to be served as 'burkhold'. It seems like there > > should be some simple way in apache to specify what user the httpd > > should be set to when it's spawned, but except for the global User: I > > haven't found a way. > > > > An httpd process is spawned to handle _all_ locations, that is why the > Group/User can only be specified per server. If apache was able to spawn > separate processes to only handle one location, your suggestion would > work. > > The only solution i would offer would be to proxy all requests to > that location to another apache server, running on a different port, > as user bukhold. The main server could then run with whatever user is > appropriate, and have a ProxyPass directive to forward requests requiring > user burkhold. > > > sterling > > > > > > If I can't make this work, I may have to turf module handlers and go > > with a Registry and setuid solution, which I think would be a shame > > since I think handlers are a lot more elegant. > > > > This is probably well-trodden territory - anyone got a solution? > > > > Thanks again, several of you have been helpful to me, and I do > > appreciate it. > > > > Happy Easter. > > > > file://Thomas > > Thomas K. Burkholder > > [EMAIL PROTECTED] > > > >
Re: mac_check in eagle book
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes: > On 2001-04-15 23:52:38, [EMAIL PROTECTED] wrote: > > > > > I was wondering if someone could explain to me why in the eagle book > > > it is necessary to perform an md5 twice before sending a mac_check > > > to a user [...] > > > > Any hashing algorithm worth its salt shouldn't have to be done twice. > > And doing it twice may in fact expose weaknesses in the algorithm > > (though I have no evidence to support this). > > Doesn't the Eagle book mention somewhere that this is done because of a > known weakness in the MD5 algorithm? There is a theoretical weakness in md5 if the attacker can create both sets of data that are hashed. Under some strict circumstances, he could get two different files with the same hash value. However, the real world risk of this is supposedly quite low and the attack is computationally difficult to perform. The double hashing reduces the risk further. The modperl book mentions it double hashes to prevent a malicious user from concatenating data onto the values being checked. I don't know if they are referring to this weakness, but I suspect they are. Sadly, the book doesn't seem to offer a reference for the claim as to the specific md5 vulnderability. (Hey Doug, wanna shed some light on that somewhat cryptic passage? :) It's been a while, but I believe SHA1 has yet to have a weakness found. md5 is probably secure enough for websites though. Chip -- Chip Turner [EMAIL PROTECTED] RHN Web Engineer
Re: mac_check in eagle book
On 2001-04-15 23:52:38, [EMAIL PROTECTED] wrote: > > > I was wondering if someone could explain to me why in the eagle book > > it is necessary to perform an md5 twice before sending a mac_check > > to a user [...] > > Any hashing algorithm worth its salt shouldn't have to be done twice. > And doing it twice may in fact expose weaknesses in the algorithm > (though I have no evidence to support this). Doesn't the Eagle book mention somewhere that this is done because of a known weakness in the MD5 algorithm? - ams
Re: mac_check in eagle book
[EMAIL PROTECTED] (Eric Kolve) wrote: >I was wondering if someone could explain to me why in the eagle book it >is necessary to perform >an md5 twice before sending a mac_check to a user of a number of >fields. I read in the mod_perl book that this is done 'to prevent >technically savy users from appending data to the @fields'. > >my $mac_check = md5_hex($secret, >md5_hex(join '', $secret, @fields)); > > >What I am wondering is, what situation would a user be able to append >data to the fields? I believe if you change only one bit of the data, >the mac will change, so I am a little confused. This looks suspicious to me too. Any hashing algorithm worth its salt shouldn't have to be done twice. And doing it twice may in fact expose weaknesses in the algorithm (though I have no evidence to support this). I'd suggest just this: my $mac_check = md5_hex join '', $secret, @fields; ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
mac_check in eagle book
I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user of a number of fields. I read in the mod_perl book that this is done 'to prevent technically savy users from appending data to the @fields'. my $mac_check = md5_hex($secret, md5_hex(join '', $secret, @fields)); What I am wondering is, what situation would a user be able to append data to the fields? I believe if you change only one bit of the data, the mac will change, so I am a little confused. thanks, --eric
Unwanted "\n" in output
Hello everybody , I have some Apache::ASP scripts that work like a XML::RPC . The idea is to send some XML request and the response will be an answer in XML that can be used by the client software. One of my scrips has a problem that in the response , 7 times a '\n' charecter is put before the actual XML text (seen by using ethereal ). This confuses my clients XML parser (M$ parser ). I don't know where these characters come from. The ouput i generated doesn't have it. I already tryed Response->Binarywrite and flushing but this doesn't do the trick. Does anybody know where this comes from ? greetings, luc
Re: Apache growing.
On Mon, Apr 16, 2001 at 04:44:23AM +0530, [Aquitaine] wrote: > Have a slight problem with my mod_perl script, > Every time i run it i notice that apache grows in size. The increase in size > is about > 10 kb per 100 executions, but if this carries on i cant put the script on in > a production environment. > Can someone help me figure why this is happening ? > Will mention that I am using DBI in the script to connect to a MySQL server. We have the same problem. I believe my code is squeaky clean but each Apache process's unique pages count increases with time. Still, 10kb/100req isn't all that bad. Make use of MaxRequestsPerChild. At a rate of 500, you will still win on the reduced overhead and not have Apache processes that grow out of control. I scoffed at the idea when I first heard it, but was much happier to consider it after I reached my wits end. It works nicely with that variable set, so I'll leave it at that. (I'm not sure this is even a code problem. Maybe perl is just bad at keeping a single consistent working set and the copy-on write from the parent Apache kicks in and keeps increasing unique per process memory consumption). -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / System Development, New York Connect.Net, Ltd.
Apache growing.
Hey all, Have a slight problem with my mod_perl script, Every time i run it i notice that apache grows in size. The increase in size is about 10 kb per 100 executions, but if this carries on i cant put the script on in a production environment. Can someone help me figure why this is happening ? Will mention that I am using DBI in the script to connect to a MySQL server. Thought that perhaps it is happening because of the multipler connect requests But i have Apache::DBI on the server so that should take of the connect statements i think I am new to mod_perl so perhaps i am missing something here. I ran my script with Apache::Leak and that left me a clean error_log file so i am at a loose end, would appreciate any help .. Thanks Aquitaine
mac_check in eagle book
I was wondering if someone could explain to me why in the eagle book it is necessary to perform an md5 twice before sending a mac_check to a user of a number of fields. I read in the mod_perl book that this is done 'to prevent technically savy users from appending data to the @fields'. my $mac_check = md5_hex($secret, md5_hex(join '', $secret, @fields)); What I am wondering is, what situation would a user be able to append data to the fields? I believe if you change only one bit of the data, the mac will change, so I am a little confused. thanks, --eric
Re: is Apache::Request upload->fh lazy or not?
Joe Schaefer <[EMAIL PROTECTED]> writes: > Apache::Request would be a nice feature. Recently David Prosa added ^^^ Ugh- he's David *Welton*, and he's using libapreq in his mod_dtcl module. Damn, that's twice I've done that to him - I'm very, very sorry, David :( -- Joe Schaefer
Re: is Apache::Request upload->fh lazy or not?
"Thomas K. Burkholder" <[EMAIL PROTECTED]> writes:
> Hi again,
>
> Thanks to those who helped me with the install issue. I've mostly
> resolved that, and now have a new question that seems much more
> mod-perl-ish:
>
> I have code that does essentially this:
>
> sub handler {
> my $r = shift;
> $r = Apache::Request->new($r);
> my $handle = $r->upload('filename');
> my $fh = $handle->fh;
> ...
> }
>
> I'd like to write upload code that shows progress (via a fork and
> refresh header trick - don't worry about that). What I'm wondering is,
> by the time I get $fh above (or even by the time I'm in the handler for
> all I know) do I already have the entire file uploaded, or is it done
> lazily as reads are performed on $fh? I'm not very good at reading this
> XS stuff, but I looked at libapreq and from that I suspect it's all done
> up front. Is there any way to read it incrementally?
>
> Has anyone solved this problem before? I want to provide an upload
> function for my web app that shows the user periodic progress or maybe
> even allows them to cancel it part way through. Is this too much of a
> reach for http/mod_perl?
I've managed to do this in the past by modifying mod_proxy on the
front-end server, but I think the ability to do this from within
Apache::Request would be a nice feature. Recently David Prosa added
an upload hook to the C API for libapreq, and yesterday I put together
a patch to Request.xs that provides a Perl interface.
It would work something like this:
my $hook = sub {
my ($upload, $buf, $len, $data) = @_;
my $fh = $upload->fh;
print $fh $buf;
warn "HOOK_DATA = $data: wrote $len bytes for " . $upload->name;
}
my $apr = Apache::Request->new( Apache->request,
HOOK_DATA => "Some parameters",
UPLOAD_HOOK => $hook,
);
my $parm_table = $apr->param; # causes upload parsing to begin
my $upload = $apr->upload('file');
my $fh = $upload->fh;
...
In this case, &$hook will be called in place of the normal internal
(buffered) writes to a temp file. Note that $upload->fh now
must auto-vivify a temp file if none was created by libapreq itself.
That's probably a feature, but it may require some care if the hook sub
is poorly designed. $upload->size will now count the size of the data
sent by the browser, which may or may not be the same as the size of
the temp file (depending on what the hook does with it). Otherwise
upload objects should behave normally ($upload->fh still dup's and
seek's outside of the hook sub).
I'll post the diff to the apreq-dev list after I've tested it a bit
more. Also, please contact me or follow up to the list if anyone has
some comments/suggestions for improving the API before committing it to
CVS.
Thanks.
--
Joe Schaefer
Build problem (lperl)
I'm trying to have mod_perl build apache during its own build, but I'm getting an error that I can't dig any answers up on. I have the libperl.so.5.6.0 in /usr/lib, but I'm uncertain how to get compiler to recognize that it is there. I ran ldconfig, but still no luck. Here's the command I'm using (I'm trying to use Slashcode, and they have this in their directions): perl Makefile.PL APACHE_SRC=../apache_1.3.19 DO_HTTPD=1\ USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1 \ APACHE_PREFIX=/usr/local/apache And here's the output: Will configure via APACI cp apaci/Makefile.libdir ../apache_1.3.19/src/modules/perl/Makefile.libdir cp apaci/Makefile.tmpl ../apache_1.3.19/src/modules/perl/Makefile.tmpl cp apaci/README ../apache_1.3.19/src/modules/perl/README cp apaci/configure ../apache_1.3.19/src/modules/perl/configure cp apaci/libperl.module ../apache_1.3.19/src/modules/perl/libperl.module cp apaci/mod_perl.config.sh ./apache_1.3.19/src/modules/perl/mod_perl.config.sh cp apaci/load_modules.pl.PL ./apache_1.3.19/src/modules/perl/load_modules.pl.PL cp apaci/find_source.PL ../apache_1.3.19/src/modules/perl/find_source.PL cp apaci/apxs_cflags.PL ../apache_1.3.19/src/modules/perl/apxs_cflags.PL cp apaci/mod_perl.exp ../apache_1.3.19/src/modules/perl/mod_perl.exp PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled PERL_MARK_WHERE.enabled (experimental) Will run tests as User: 'nobody' Group: 'root' (cd ../apache_1.3.19 && CC="cc" CFLAGS=" -DPERL_MARK_WHERE=1 -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ./configure --activate-module=src/modules/perl/libperl.a --disable-rule=EXPAT --prefix=/usr/local/apache) Configuring for Apache, Version 1.3.19 + using installation path layout: Apache (config.layout) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src + id: mod_perl/1.25 + id: Perl/v5.6.0 (linux) [perl] cd ..; cc -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DNO_DL_NEEDED -DPERL_MARK_WHERE=1 -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 `./apaci` -I. -I/usr/lib/perl/5.6.0/CORE-o helpers/dummy helpers/dummy.c -lm -lcrypt -rdynamic -L/usr/local/lib /usr/lib/perl/5.6.0/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl/5.6.0/CORE -lperl -lnsl -ldl -lm -lc -lcrypt /usr/bin/ld: cannot find -lperl collect2: ld returned 1 exit status make: *** [dummy] Error 1 Thanks in advance, -- Sean LeBlanc - [EMAIL PROTECTED] A programmer is someone who solves a problem you didn't know you had in a way you don't understand.
Re: modperl security model question
On Sun, 15 Apr 2001, Thomas K. Burkholder wrote: > Thanks again for the help - I have another one- > > My application consists of perl modules with file permissions set only > to a particular user 'burkhold'. The database password is kept in > plaintext in one of those modules. I use the User: and Group: > directives in access.conf to cause the uid of the spawned httpd process > to have permission to execute the code. It works fine, except that it > seems I can't embed 'User: burkhold' inside a directive, so > all requests have to be served as 'burkhold'. It seems like there > should be some simple way in apache to specify what user the httpd > should be set to when it's spawned, but except for the global User: I > haven't found a way. > An httpd process is spawned to handle _all_ locations, that is why the Group/User can only be specified per server. If apache was able to spawn separate processes to only handle one location, your suggestion would work. The only solution i would offer would be to proxy all requests to that location to another apache server, running on a different port, as user bukhold. The main server could then run with whatever user is appropriate, and have a ProxyPass directive to forward requests requiring user burkhold. sterling > If I can't make this work, I may have to turf module handlers and go > with a Registry and setuid solution, which I think would be a shame > since I think handlers are a lot more elegant. > > This is probably well-trodden territory - anyone got a solution? > > Thanks again, several of you have been helpful to me, and I do > appreciate it. > > Happy Easter. > > //Thomas > Thomas K. Burkholder > [EMAIL PROTECTED] >
