Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Hello everyone!
I've recently set up a web server, for users to upload files onto and
run .php and CGI/Perl scripts, namely, a regular webhosting service.
Now the problem that I've encountered, is creating a chrooted jail for each user, to prevent their creating scripts that could compromise the server, or even course through(I've got nothing to hide, but still...).
The site runs on users.mydomain.com, and each user root is at users.mydomain.com/$username;
Normally, if the document root were seated directly on the root of the virtual host, I'd have no difficulty in creating a jail like that; but my configuration requires the use of a subdirectory for each user, in part for avoiding the creation of a Vhost for each user.
In this case, I am entirely lost!
Is such a thing even feasible?
How can it be done?
Very thankful for your attention,
Beholden,
Daniel
Have you tried installing/configuring a FTP server ? You can create users and point them to the users.mydomain.com/$username path in the ftp configuration file.
Thanks for your replies, a few more clarifications needed...
Hello!
Thank you both for truly helpful suggestions.
@vicky, I am afraid an FTP server is out of the question at the moment, as I don't have enough external IPs (yet), and have already exploited those that I do have to the maximum. I would very much like to bind a future FTP host on a separate IP, to avoid misuse.
@Bathory, your advice works wonders, but executing abs_path in Perl still offers the direct path, i.e /var/www/.../$username; Meaning that a non-benevolent user might manipulate this path and scroll or "cd" wherever he likes.
So this still persists... sadly .
What else can be done?
Thanks again,
Daniel
First of all guys, I wanted to thank you for all your tremendous aid, it's been absolutely invaluable!
@bathory, I've looked into it, but I couldn't get any headway with mod_security, not being familiar enough with the module, I guess; If you could provide me with a means to start, i.e, what in my case, my condition for denying a request should be, and how would it incorporate the physical path in it, I'd really appreciate it!
How do I go forward?
Thanks,
Daniel
Hi there!
Firstly, let me thank you for a very handy tool you've granted me. I've added quite a few security arrangements via "mod_security", and it works like a charm, thanks!
However, it is impractical in the broder sense of my query, because it can't read the code of an executing CGI script; so if anyone chooses to
Code:
openfile(..., "/etc/passwd")
they'll still be able to do it, regardless of my attempts to block it via Apache.
So I've settled with setting new permissions, in the form of 740/750, and chowning each Cgi script to the respective user. Then, via Suexec(in Apache), running them as such.
I've also thought of creating a chrooted jail for the entire HTTP server, but that seems like quite a hassle.
So what do you think, is this secure enough?
How do other hosting servers get by?
Very grateful for you help,
Daniel
Last edited by danielakkerman; 11-14-2011 at 11:35 AM.
Reason: Typo discovered
As I've already told you, I have no idea about locking such perl scripts. Maybe taint mode should do, but you have to test every script and see how it does.
If you are that much concerned about security, you should use a RHEL-based distro and use the SELinux security access control. Also debian based distros have apparmor, that does the same thing.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.