Re: Web-page based proxy service

2005-01-14 Thread Blair Strang
Peter Clark wrote:
I would like to provide a proxy service that can be used only by accessing 
a web page. In other words, I don't want users to enter proxy details in 
their browser settings, but rather, if they want to go through a proxy, they 
can visit a webpage, enter a URL in a form, and the page (and all subsequent 
pages) will be funneled through the proxy to the user. I believe that 
anonymizer.com does something similar. But hopefully you get the idea.
:Peter
I played around with CGIProxy for a while, although I don't really use it 
anymore.
Might suit your needs.
http://www.jmarshall.com/tools/cgiproxy/
I found it didn't work very well for JavaScript heavy stuff like Hotmail (which
is to be expected) but for most sites it worked adequately.
I had to apt-get install libnet-perl libnet-ssleay-perl and make a minor change 
to
the script at line 3935:
#   $how_much -= Net::SSLeay::blength($got);
$how_much -= length($got);
Coz Net::SSLeay::blength wasn't working for me.
Cheers,
Blair.



signature.asc
Description: OpenPGP digital signature


Re: suexec permissions

2005-01-10 Thread Blair Strang
nodata wrote:
Done. chmod o+rx on:
 /var/www/bob
 /var/www/bob/htdocs
 /var/www/bob/cgi-bin
then running a system("touch /tmp/blairtest") from cgi-bin/test.pl creates
a file with bob:bob permissions.

The other thing to check is that your scripts are physically located under
suEXEC's DOC_ROOT (/var/www on Sarge, I think).

They are.

Regards,
   Blair.

The problem with this setup is that I have to have o+rx permission on
directories and non-executables, which is a little messy (and I'm not sure
whether vsftpd can handle this).
Plus everyone on the machine can now read the files.
Ack.
Well, to get /proper/ isolation you have to run separate Apache 
instances... :)
You could try a compromise along the lines of that suggested by Upayavira, 
except
you hit NGROUPS_MAX as you noted.
Wild Ass Suggestion: If you made each user VirtualHost directory uid  gid
www-data, and mode 2750 (note the setgid bit there), and have only Apache in 
group
www-data, might that not work?  [Am I missing something obvious?]
The biggest problem then is that users can piggyback off Apache's group www-data
access by running scripts.  Perhaps this could be surmounted with suexec, by 
forcing
scripts to run as the User/Group you specify.  Users might have to manually 
chgrp
their scripts to their "User Private Group" in this scenario though, which is a
disadvantage.
But I should shut up now... I have to defer at this point to someone with more
experience at running large Apache installations.  8-P
Regards,
Blair.


signature.asc
Description: OpenPGP digital signature


Re: suexec permissions

2005-01-10 Thread Blair Strang
nodata wrote:

nodata wrote:
Ah this would explain things more - but then shouldn't running
http://website/cgi-bin/test.pl work? I get the same search permissions
error..
Er, yep, as far as I can see, it should.  suEXEC can be a little...
finicky :)
What does /var/log/apache/suexec.log say?

Nothing :/
But the error log for this host has the "failed because search permissions
are missing on a component of the path" error.
A couple of things.
The suEXEC wrapper itself does setuid() before most of the path/file checks,
so that's probably not the problem.  The absence of anything in the log file
also indicates that Apache itself is having trouble reading things, not the
suEXEC wrapper.
You might want to try loosening the read permissions on the CGI + path to the
CGI, and verify (by perhaps touching a file in /tmp) that it is running as the
user you intended it to.  Then try tightening the read permissions on the CGI
itself, and then along the path to it.
The other thing to check is that your scripts are physically located under
suEXEC's DOC_ROOT (/var/www on Sarge, I think).
Regards,
   Blair.


signature.asc
Description: OpenPGP digital signature


Re: suexec permissions

2005-01-10 Thread Blair Strang

nodata wrote:
Ah this would explain things more - but then shouldn't running
http://website/cgi-bin/test.pl work? I get the same search permissions
error..
Er, yep, as far as I can see, it should.  suEXEC can be a little...
finicky :)
What does /var/log/apache/suexec.log say?
Ta,
Blair.


signature.asc
Description: OpenPGP digital signature


Re: suexec permissions

2005-01-10 Thread Blair Strang
nodata wrote:
Good morning,
I'm having a some permissions trouble with suexec running on Sarge.
I have a virtualhost for a user called Bob which specifies User Bob and
Group Bob in the /etc/apache/conf.d/bob.conf file.

If I switch user to bob, and run ls -la on /, /var, /var/www, /var/www/bob
I can see all of the files, so why is apache running as this user not able
to?

Hiya,
You'll probably find that all your Apache processes are running as www-data
based on the User directive in your main httpd.conf -- and they can't read
bob's files.  Only CGI scripts will be affected by the "User" directive in a
VirtualHost.
From: http://httpd.apache.org/docs/mod/core.html#user
"Special note: Use of this directive in  requires a properly
configured suEXEC wrapper. When used inside a  in this manner,
only the user that CGIs are run as is affected. Non-CGI requests are still
processed with the user specified in the main User directive."
Regards,
Blair.


signature.asc
Description: OpenPGP digital signature


Re: distributing SSH keys in a cluster environment

2004-10-29 Thread Blair Strang
Based on a cursory look at how FAI works, if you're worried about
a 'laptop attack' -- i.e, an untrusted person with access to your network
media -- I think there are more problems than just SSH keys.
None of the tftp/dhcp/pxe stuff is really designed with security
in mind.  It seems to me that anyone could compromise an initial install
by messing with the boot process.  Noisy, but do-able.
[Unless I've misunderstood the threat model you're positing here]
From this point of view, I can see no reason not to just jigger a fixed
host key for the initial install, followed by a keychange over SSH.  Mark's
suggestion also seemed good.
Regards,
Blair.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]