I have freebsd 4 running on my servers. I run ftpchroot so users can only see their directories will ftpd in. Is there a way to make it the same way for telnet? Right now users can telnet in and browse other users home and public_html directories(and can copy the files if they want). What chmod should be used to fix this? Thankyou... btw each user is in their own login/group


David

Permissions on any file or directory should always be as little as possible. Nothing should be opened up for anyone to view unless it needs to be this way.

How to lock down your system really depends on a few things:

- Who needs to access each user directory?
In other words, what user does your webserver run as? I always run Apache as user 'apache'.

- Will locking out the world affect other software?
Do you run any software that needs to go into a user's home directory while running as someone else? Some mailing list software might need to access user directories, for example.

If you've determined that only the domain owner and 'apache' need to access home directories, do this for each user. We'll use "john" for the example:

chown john.apache /home/john

This makes /home/john owned by user "john" and group "apache". Yes, it's fine that "john" is not in the apache group (he shouldn't be).

Then:

chmod 0750 /home/john

This says that "john" can read, write, and search his directory. "apache" can read and search. Everyone else will get a "permission denied" error.

Finally, once you've done this for each home directory, keep users from seeing other home directories as well:

chmod 0751 /home

They can enter /home, and go into their own directory, but they won't get a directory listing of the contents of /home.

If you have a lot of users, the above can take a while; or, you can be a sysAdmin and use a one-liner like this:

for i in `/bin/ls /home`; do chown $i.apache /home/$i; chmod 0750 /home/$i; done

(all one line there)

Other things you might want to do:

chmod 0751 /etc
chmod 0751 /sbin
chmod 0751 /usr/sbin

Perhaps a few others... At any rate, file permissions exist for a reason; figure out who needs what type of access, and give them only that type of access. Default installs are never very secure, and many things may need to be changed around to make things secure.

Notes:
If the above breaks things, take a look at the things it's breaking. Evaluate what user each process is running as. If your mailing list software is no longer able to access home directories, what user is it running as? Maybe it should run on behalf of the user (Qmail with ezMLM is great for this).

Really the best way to find out what users are allowed to access is to become a normal user. Log in as a standard user, and browse around. Are you looking at something you shouldn't be looking at? Become root and fix it. It's not always as easy as a 'chmod', but with some creative thinking you can lock your system down tight.

The best way to learn is through experience, and it takes a while to get to the point where you can lock a system down for a multi-user environment. But this is a necessary step; would you want fellow-webmasters on your shared server looking at, for example, /home/yourname/creditcards.txt? Or /home/yourname/my_php_script_complete_with_mysql_password.php?

PS - sorry for the long rant; security is so often overlooked in this business, when it should come before anything else IMO...

Thanks a ton for the help...and no it wasnt a long rant. I never thought of running apache as a user apache. I think that will clear may things up and lock the users out how I want.

Thanks again
David

What about scripts?

CGI scripts are usually ran as the user the apache server is running as. If apache has access to all the home dirs, any user on the system with a website can have a CGI run by apache that will read other home dirs.

My solution is to use CGI WRAP. I have all scripts running as the user owning it. So when apache runs a script it is just like if the user would run that script in telnet.

Although, it works only for CGI's, so if you use PHP, you have to use the CGI version which is a big disadvantage, but you have no choice if you want a secure system.

System administration is more complicated than what most sys admin think.

Thank you,

cedric

Another thing:

Server Side Includes. It is possible to execute script using the EXEC SSI command that will be ran as user 'apache'. You have to use IncludesNoExec, to prevent this and have your users use VIRTUAL instead od EXEC I think. It will exec the script like a CGI.

I didn't go into scripts in my previous post for two reasons: first, the question was about directory permissions (not that the topic has ever stopped me before), and second, I was already ranting quite a lot on the subject at hand :)

I always run Apache's suEXEC wrapper, so all CGI scripts are run under the domain owner's userID. PHP is run in safe_mode with the open_basedir set to that user's home directory. You lose your exec() family of functions, but you also lose the ability to read other people's files, which is the goal.

I also disable the SSI exec features (but leave includes/virtuals), and I enable following symlinks only if owned by the user (though you can't create a link to a file if you don't have appropriate permissions anyway).

The only issue I have with PHP safe_mode is that if PHP creates a directory, then places files within that directory, the user cannot delete them. The OS won't let them since they don't own the directory, and PHP won't let them because of safe_mode...

One could write volumes of books on how to properly secure a web server. In fact, many people have. I enjoy these types of discussions, though, as I hope they help to educate those who aren't aware of these things. Once you've been hacked once, you'll take security a LOT more seriously. I know this because I had one of my home systems hacked a few years ago (thanks to wu-ftpd), and have been paranoid since.
System administration is more complicated than what most sys admin think.
I'll probably get in trouble for saying this here, but I do disagree with this statement. System administration is extremely difficult, but those who don't know this are NOT systems administrators. They may think they are, but if you rely on a control panel for administration, and you don't know how to evaluate file/directory permissions and lock down your system, you should not be allowing users to use your system -- especially if they are expecting some level of security and competence, trusting you with personal/sensitive information of both them and their customers. You can only hide behind a control panel for so long... but I digress...