Secure permissions

M

martinostlund

Verified User
Joined
Feb 10, 2011
Messages
13
Hello,

I've noticed some permissions that are a bit to generous, atleast in my opinion.
These might not directly impact system security, but it will give away information about customers to anyone with a web account and some perl/php skills.

My main concern is that users are able to read files from /etc/virtual, like domains, domainowners etc.

Also, /var/www/html is readable, and with roundcube installed users can read the database password in
/var/www/html/roundcube/config/db.inc.php

Is there any (good) way to only have the system services read these files, or can I somehow limit the access to these directories with php/apache? Im using suPHP.

Best regards,
martin
 
mr.applesauce said:
So use chmod and chown to change them to what you think is more secure.
Click to expand...

Yes I can do that, without ever knowing if I break something badly what will come back and smack me in the face in two weeks, I want input on what others have done that has taken that path and have the experience that I dont.

Do YOU know anything, Mr Applesaucege?
 
At least you can chmod:

Code: 
# ls -ld /etc/virtual
drwxr-x--x 10 mail mail 4096 Feb 10 18:02 /etc/virtual

Code: 
# ls -ld /var/www/html
drwx--x--x 11 root root 4096 Feb 10 00:23 /var/www/html

If you want more, you need to tell us, how are things organized on your server. Are you running Apache with or without mod_ruid2. What PHP version are you using: CLI or CGI?
 
Well for one you shouldnt be giving your users ssh access at all. If you are disabling dangerous php functions then i dont see how users are going to be able to get into areas they are not supposed to. There are about a million different areas in the system they can get to if they can change directories around your server if they are given the opportunity to do so.
 
Hello,

1) I've tested:
Code: 
chown webapps:apache /var/www
chmod 550 /var/www
with suPhp (cgi) and didn't notice any issues. In theory, CLI php should be fine too.

If we can get a more confirmations that this is ok, I'll make it default for new installs. (I'd be hesitant to do it on existing installs)

2) The /etc/virtual directory has a decently large number of different UID's accessing it. Locking it down at the /etc/virtual level might be tricky.

We could piggyback onto the secure_access_group feature and try:
Code: 
chgrp access /etc/virtual
chmod 750 /etc/virtual
but I'm not sure if that's going to break anything.

For one, I can see that the /etc/virtual/domain.com/filter is read in by the User, so we'd have to edit the /etc/exim.conf and change the section for domain_filter:
Code: 
user = "${lookup{$domain}lsearch{/etc/virtual/domainowners}{$value}}"
to be
Code: 
user = "mail"

I've not tested this on the /etc/virtual yet, so I'm not positive. (going on an email reply received today by martinostlund). There may be more areas for edit in the exim.conf.

John
 
Update: we can't change the domain_filter user permissions, since the filter itself needs to write to the spambox, which needs those user permissions, so all DA Users needs to be able to read their respective domains in /etc/virtual. The next thing to try would be "access" group on /etc/virtual/domain.com with chown user:access... and chmod 570 (weird, yes). We don't want the user to have write access, but he needs to read.. but we still need all other system accounts to see in still.. I'm not sure if that would work or not.

John
 
DirectAdmin Support said:
Update: we can't change the domain_filter user permissions, since the filter itself needs to write to the spambox, which needs those user permissions, so all DA Users needs to be able to read their respective domains in /etc/virtual. The next thing to try would be "access" group on /etc/virtual/domain.com with chown user:access... and chmod 570 (weird, yes). We don't want the user to have write access, but he needs to read.. but we still need all other system accounts to see in still.. I'm not sure if that would work or not.

John
Click to expand...

Hello.

My solution for securing /etc/virtual was to first chmod o-rx /etc/virtual/*
Then, for current domain.com directories, I change group ownership to 'user' and set chmod g+rx to /etc/virtual/domain.com

Also I made in user_create_posh.sh:
/bin/chgrp $username /etc/virtual/$domain
/bin/chmod g+rx /etc/virtual/$domain
/bin/chmod g+rx -R /etc/virtual/$domain/*

I don't know if my solutions is good or bad, I havent noticed any problems yet, perhaps someone on this forum can point it out?
 
Hello,

Majordomo uses:
majordomo:daemon

at /etc/virtual/domain.com/majordomo/*

Uebimiau (if you use it, which I'd advise against anyway) would access /etc/virtual/domainowners with apache (cli), or webapps (suPhp/cgi)

If you don't need either, then your solution might work.

John
 
DirectAdmin Support said:
Hello,

Majordomo uses:
majordomo:daemon

at /etc/virtual/domain.com/majordomo/*

Uebimiau (if you use it, which I'd advise against anyway) would access /etc/virtual/domainowners with apache (cli), or webapps (suPhp/cgi)

If you don't need either, then your solution might work.

John
Click to expand...

Yes, I dont use Uebimiau, only roundcube.
/etc/virtual/domain.com is owned mail.user and with permissions of drwxr-x--x
which seems to work fine.

/Martin
 
Many of us still use majordomo (including me).

Please John, if you're going to make changes to exim.conf, let me know, so I can keep my version up to date.

Thanks.

Jeff
 
While I like Mailman as well, I'm afraid we'd still need to support our clients using Majordomo.

What special kind of MailMan support would you need? You should be able to install it, and it has it's own web-based interface.

Jeff
 
DirectAdmin Support said:
Update: we can't change the domain_filter user permissions, since the filter itself needs to write to the spambox, which needs those user permissions, so all DA Users needs to be able to read their respective domains in /etc/virtual. The next thing to try would be "access" group on /etc/virtual/domain.com with chown user:access... and chmod 570 (weird, yes). We don't want the user to have write access, but he needs to read.. but we still need all other system accounts to see in still.. I'm not sure if that would work or not.

John
Click to expand...


John, do you have any updated information regarding securing /etc/virtual from other users on the systems, reading the files of this directory with php/perl/whatever scripts?

Regards,
Martin
 
So far (I didn't do much testing with it) I know that all User accounts need access to it, so /etc/virtual can be, at the lowest, 711, as I don't think anything needs to scan it for what's in it. Anything that ventures into /etc/virtual knows what it's looking for.

I didn't check past that, but I believe the /etc/virtual/domainowners and /etc/virtual/doamins can be tightend slightly to block Users from seeing them. (not confirmed). For sure you'd want apache, webapps, nobody, mail, majordomo, daemon to be able to read them (ie: "access" group, 640).

Then each /etc/virtual/domain.com could be readable by access group, plus the user. Maybe user:access, chmod 570 (I think). We don't want the User writing in there, hence 5, but need the group feature for all of the other accounts, hence user:access 570.

Again, I've not done testing with this, so I'm not too sure.


I have done testing with /var/www, setting it to webapps:apache 550, and that seems to work ok (didn't notice any issues), so I'll probably be adding that into custombuild soon. Feel free to try it to test it out, in case I've missed anything.

John
 
You must log in or register to reply here.
Back
Top