Re: virtual hosting
Hello, The only question I have in this setup is why would you need to chroot everything. In a typical hosting environment where users have FTP access to the server to upload web pages, you can just chroot the FTP daemon to the individual user's upload directory. As far as Apache, you could chroot the daemon to the directory where all your websites reside. But in that situation, I do believe you would need to copy all the binaries you would want to run (i.e. Perl, PHP, MySQL, etc.), but I could be wrong on that point. Hope that helps a bit. Regards, jovan rivera [EMAIL PROTECTED] On Tue, 26 Mar 2002 15:49:56 +0100 Michal Novotny [EMAIL PROTECTED] wrote: Hello! It is possible to make virtual web hosting (apache) in chroot jail? There is a little problem with about 1500 domains/clients. How can I set it up (with perl/php/ssi/ssl/cgi/ftp/mysql etc.) ? I think it have to be all in the chrooted directory, so will it be apache/perl/mysql/libs for each domain? or could it be symlinked? I do not imagine about 1500 chroots... But I think if it can work then it will be so secure, isn't it? Regards Michal Novotny -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: virtual hosting
Hello, The only question I have in this setup is why would you need to chroot everything. In a typical hosting environment where users have FTP access to the server to upload web pages, you can just chroot the FTP daemon to the individual user's upload directory. As far as Apache, you could chroot the daemon to the directory where all your websites reside. But in that situation, I do believe you would need to copy all the binaries you would want to run (i.e. Perl, PHP, MySQL, etc.), but I could be wrong on that point. Hope that helps a bit. Regards, jovan rivera [EMAIL PROTECTED] On Tue, 26 Mar 2002 15:49:56 +0100 Michal Novotny [EMAIL PROTECTED] wrote: Hello! It is possible to make virtual web hosting (apache) in chroot jail? There is a little problem with about 1500 domains/clients. How can I set it up (with perl/php/ssi/ssl/cgi/ftp/mysql etc.) ? I think it have to be all in the chrooted directory, so will it be apache/perl/mysql/libs for each domain? or could it be symlinked? I do not imagine about 1500 chroots... But I think if it can work then it will be so secure, isn't it? Regards Michal Novotny -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ulimits
Hello, Here are some answers to the questions you asked. If anyone realizes that any of the information is incorrect or inaccurate, please feel free to correct me :-) On Sat, 23 Mar 2002 09:30:36 +0200 Hugo van der Merwe [EMAIL PROTECTED] wrote: Hello, Recently a friend of mine was kind enough to hit refresh 700 times after requesting a depth 5 recursive validation from the validator on my web server. It's load levels went to above 150, hehe. Took me a couple of minutes to log in, and a couple to su to root, and more than 5 minutes to get the killall validate.cgi command executed. Quite amazing that the machine survived it all. GNU/Linux rules! ;) Now I realise the time has come for me to set up some ulimits. I have some queries about the workings of /etc/security/ and /etc/pam.d/. If I set up limits in /etc/security/limits.conf, this will only apply to pam-enabled services with pam_limits.so in the corresponding file in /etc/pam.d/ ? Or does login cover everything? If you edit /etc/pam.d/login to use pam_limit.so, it will set up limits for UIDs that utilize the login program (i.e. /bin/login) in some way. I see the following in pam.d/kde: password required pam_unix.so nullok obscure min=4 max=8 md5 What is the effect of this? I wanted to make my passwords 6 to 12, so I editted pam.d/login, is it necessary to e.g. edit the kde one too? (Everything appears to work well.) When a PAM module has the control flag of password, the module is concerned with password management, such as setting/resetting the authentication token of a user. The line actually has no bearing on password creation, since the file that would really matter for that would be /etc/pam.d/passwd; in a simple sense it means that whenever KDE makes a call to refresh the user's authentication token, it will only care about a maximum of 8 characters of a user's password. How would I give apache some ulimits, so that it doesn't spawn too many validators, or eat too much ram? (To me it doesn't look like simply editting /etc/security/limits.conf will work out of the box ?) Try invoking umlimit from the apache initialization script. Thanks, Hugo van der Merwe ps: please CC. (busy week) A good resource on Linux-PAM can found at: http://www.kernel.org/pub/linux/libs/pam/ Regards, jovan rivera [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ulimits
Hello, Here are some answers to the questions you asked. If anyone realizes that any of the information is incorrect or inaccurate, please feel free to correct me :-) On Sat, 23 Mar 2002 09:30:36 +0200 Hugo van der Merwe [EMAIL PROTECTED] wrote: Hello, Recently a friend of mine was kind enough to hit refresh 700 times after requesting a depth 5 recursive validation from the validator on my web server. It's load levels went to above 150, hehe. Took me a couple of minutes to log in, and a couple to su to root, and more than 5 minutes to get the killall validate.cgi command executed. Quite amazing that the machine survived it all. GNU/Linux rules! ;) Now I realise the time has come for me to set up some ulimits. I have some queries about the workings of /etc/security/ and /etc/pam.d/. If I set up limits in /etc/security/limits.conf, this will only apply to pam-enabled services with pam_limits.so in the corresponding file in /etc/pam.d/ ? Or does login cover everything? If you edit /etc/pam.d/login to use pam_limit.so, it will set up limits for UIDs that utilize the login program (i.e. /bin/login) in some way. I see the following in pam.d/kde: password required pam_unix.so nullok obscure min=4 max=8 md5 What is the effect of this? I wanted to make my passwords 6 to 12, so I editted pam.d/login, is it necessary to e.g. edit the kde one too? (Everything appears to work well.) When a PAM module has the control flag of password, the module is concerned with password management, such as setting/resetting the authentication token of a user. The line actually has no bearing on password creation, since the file that would really matter for that would be /etc/pam.d/passwd; in a simple sense it means that whenever KDE makes a call to refresh the user's authentication token, it will only care about a maximum of 8 characters of a user's password. How would I give apache some ulimits, so that it doesn't spawn too many validators, or eat too much ram? (To me it doesn't look like simply editting /etc/security/limits.conf will work out of the box ?) Try invoking umlimit from the apache initialization script. Thanks, Hugo van der Merwe ps: please CC. (busy week) A good resource on Linux-PAM can found at: http://www.kernel.org/pub/linux/libs/pam/ Regards, jovan rivera [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq Kernel 2.2.19
Hello,
I run Woody with 2.2.19 compiled from source, and the ptrace exploited worked
even with an older version of Openwall applied (scary...), but I snagged
fresh kernel source and the new Openwall patch, and it fails with the message
you receive ("execl: Operation not permitted.").
Regards,
Jovan Rivera
Email: [EMAIL PROTECTED]
Kenneth Pronovici wrote:
[EMAIL PROTECTED]">
Has anyone else noticed that the included exploit does not affect2.2.19? I tested it on one of my boxes and got the expected 'Operationnot permitted'. Maybe I'm misunderstanding the problem, but I thoughttaht 2.2.19 took care of (well hindered) the ptrace problems.
I can't make the ptrace exploit work on my 2.2.19 system... but I mightbe doing something wrong (I'm not quite sure what to expect). I get: attached exec ./insert_shellcode 30505 execl: Operation not permittedThe mklink.sh script definitely works as advertised. If I use an argumentof 10, I'm dead in the water until the script finishes.KEN
Re: BugTraq Kernel 2.2.19
Hello,
I run Woody with 2.2.19 compiled from source, and the ptrace exploited worked
even with an older version of Openwall applied (scary...), but I snagged
fresh kernel source and the new Openwall patch, and it fails with the message
you receive ("execl: Operation not permitted.").
Regards,
Jovan Rivera
Email: [EMAIL PROTECTED]
Kenneth Pronovici wrote:
Has anyone else noticed that the included exploit does not affect2.2.19? I tested it on one of my boxes and got the expected 'Operationnot permitted'. Maybe I'm misunderstanding the problem, but I thoughttaht 2.2.19 took care of (well hindered) the ptrace problems.
I can't make the ptrace exploit work on my 2.2.19 system... but I mightbe doing something wrong (I'm not quite sure what to expect). I get: attached exec ./insert_shellcode 30505 execl: Operation not permittedThe mklink.sh script definitely works as advertised. If I use an argumentof 10, I'm dead in the water until the script finishes.KEN
