User security ?

Other users (owners of another siteworx account) can simple view files in my html directory, because they are world readable. How can i prevent them ?

Setting proper file permissions is the most immediate answer. Make sure config files with database passwords and such aren’t world-readable.

Other restrictions like enabling safe mode are useful, too.

Thank you for reply, lineman. I’m security professional, i know how to secure scripts on website, but i don’t know, how to do it in Siteworx. Siteworx fileman created files chowned as user:user with chmod 0644. If i strip the world readability (set mode to 0640) webserver cannot read this file. And i cannot change the file owner.
Open_basedir can help, but there can be another hole in other users CGI, or EXEC possibilities. But anyway my question is as “siteworx user”, not “nodeworx user”. The default settings for any admin panel must be secure, not like this one.
I may be wrong and missed something, because i’m new in interworx.

Hi Mkuchar,

As a security professional, how do you secure a script 100% in ANY shared hosting environment? What you’re describing is not an InterWorx problem. It is a shared hosting problem.

This issue has existed for years, and as far as I know there is no truely complete solution. I’d be thrilled if someone could prove me wrong.

Paul

This is something we had to deal with on our box and it’s a pretty frustrating truth. I eventually found my only comfort was the fact that if I was able to solve it, then I would be a millionaire overnight. :wink:

One thing that is bad with any control panel (not just Iworx) is that it does the same thing for all accounts. So if a user on your server gets curious they know which directories to look for in other accounts. I know this is pretty easy because I tried something like this with a shared host because I was afraid my files were insecure. Using a PHP script one account I owned I was able to get into another account I had on the same server. I couldn’t change directories through the whole path, but if I started at the /home/pathtouseraccount/webpath it would work. When I got my dedicated server I used “Open_basedir” and that at least covered the simple hack using a PHP script.

Thats why I’m not in the webhosting business exactly. I actually manage 90% of the accounts on my server and still love InterWorx because it makes it much easier to manage everything.

And the other 10% of people I know, but those that sell accounts online to anyone anywhere that’s a though business. Also, even if someone isn’t doing something “bad”, but just have some crappy programming skills and have PHP scripts that take a lot of CPU load and memory that can really upset the other users on the server.

I guess thats why I look like :rolleyes: most of the time rather than :eek:

Wait for own panel (surePanel), which we will publish at May 1st :slight_smile: The better solution how to chown/chmod userfiles is as follows:

  1. FTP act as “user:httpd”
  2. files are chmod 0640, so broken webserver cannot rewrite userfiles and website can use “safe_mode=on” and “safe_mode_gid=on”
  3. user can give write access to some files and dirs to webserver daemon, if he want/need
  4. on all accounts (virtuals) is “open_basedir=/users/website”

What i say, this is a Interworx problem.

  1. Because of permissions model, users website cannot have “safe_mode=on”, because files are owned by user and his group.
  2. Nodeworx not set the “open_basedir” to users website.
  3. User cannot set permissions to write in file or directory by phpscript (webserver) - can only set write permissions to everyone !?

Yes, this issue exists very long time and is not 100% solved still now in conjunction with CGI apps etc.

I must say (as i’m on Interworx forum :), that Nodeworx/Siteworx is at this time the most secure controlpanel application. I tested nearly ANY others and can say, that this is only one usable. IMHO the permissions and safe_mode possibilities is the last, what is need to do in the future. Hmm and better ftp application, but this is another issue and admin can use another with your accounts database.

If you can share your million with me, we can solve it together :slight_smile:

Just a few quick comments/questions:

  1. FTP act as “user:httpd”
  • Are you going to enforce unix quotas via the uid? If so, will mysql/email/other data be under this uid umbrella or will each service have its own quotas? We’ve always been a believer that all disk resources should be under a single umbrella. This was our design decision and limits us in some aspects but I feel makes the system easier for the user.

  • Are you going to disable php’s exec, system, open etc etc functions and break many existing apps? If not I can still read your files.

  • How are you going to keep this user:httpd setup for each client applied? via sticky bits? We’ve tested some such architectures and invariably the user will reset sticky bits to make them ineffective.

  1. files are chmod 0640, so broken webserver cannot rewrite userfiles and website can use “safe_mode=on” and “safe_mode_gid=on”
  • How are you going to enforce the 0640 for new files, via umask? Many PHP (and other) scripts like to play with the umask as well so while this will work it may not be a good long term solution.
  1. user can give write access to some files and dirs to webserver daemon, if he want/need

I like this as we often do it manually for clients. But it induces other problems with file accounting (in InterWorx-CP) and is really more a user convenience than a security measure. Either way the webserver can write your files and even with safe_mode and open_basedir ‘on’ there is no help from this.

  1. on all accounts (virtuals) is “open_basedir=/users/website”

Point taken and this will be supported, along with safe_mode in iworx 2.0. Pascal has been asking for this one for a while :).

What i say, this is a Interworx problem.

  1. Because of permissions model, users website cannot have “safe_mode=on”, because files are owned by user and his group.

You can have safe_mode ‘on’ but depending on what software you are using it may cause problems. In this respect it is an InterWorx-CP problem.

  1. Nodeworx not set the “open_basedir” to users website.

Point taken (this should be noted for the previous too) and is fixed in 2.0 as noted above.

  1. User cannot set permissions to write in file or directory by phpscript (webserver) - can only set write permissions to everyone !?

Symantically there is little difference. Both are bad. Writing by everyone is worse but writing by the webserver might as well be writing by everyone in many cases.

We’ll be debuting chroot’d ssh in 2.0 and it will help with the ‘write by everyone’ problem but regardless writing by anyone other than the user himsellf is obviosly not ideal, and unavoidable.

mkuchar, thanks for all the good points, but the core problem still exists (I can read your files and write some of your files) so while I’d categorize your solution as more intense it induces some other problems with file accounting (for IWorx-CP) without actually solving the core problem.

I hope we continue this dialog after your surepanel comes out, as I see few panels actively discussing this. I wish you luck as well with surepanel!!

One final note, we have gone over this (at length) internally while developing InterWorx-CP. We’ve been a shared hosting firm since 2000 and this has obviously been a problem since day 1 (for all shared hosts). We’ve tried to balance convenience and security (and we continue to work at this) since neither is fully solvable. If it were, we’d obviosuly do it :).

Thanks again mkuchar for your comments!

Chris

This statment applies to every part of life even the non-digital ones :rolleyes:

Even as technology makes security more convenient, that means the hackers have better technology to crack it. The way I see it is a problem with a never ending solution. If you lock something someone will always try to get in.

The only real solution is to stay up to date so the kiddie hackers with day old techniques won’t be able to mess things up for you.

Both possibilities are open. Have different quotas for different services is not very bad, because as one os hosting models is to have mysql and mailserver on another machines and there is of course no other way.

I want to always disable system, exec and others. I thing open is not need to disable with safe_mode and open_basedir. If it will broke some application, user can buy VPS account. I thing, that good app don’t need exec something and if yes and can be trusted, we can set safe_mode_exec_dir

No sticky. If user write files with FTP, it is set in ftp config (user:httpd/0640). If user want to allow webapp to write to some file/directory, he change this in controlpanel (do 0660). The only problem can be, that files written from webserver will be httpd:httpd (and 0640 or 0644 depend on umask) and the user cannot change (or read too) this files with FTP (must change perms in controlpanel) and user quotas not changes.

Yes, with umask. I don’t have and don’t know any problems with it. We use it last two years.

How ? If webserver don’t have write access ?

I cannot have safe_mode on in siterorx, because scripts are owned by user:user and safe mode needs to be owned by webserver (or webserver group). Or i missed something ?

And your suexec scripts acted as other users then webserver ?

We use them, but i don’t see the difference in files write access. The main difference is that user can edit hist pages easily with vi or midnight commander.

I thing, that i solve all write/read problems, but broke quotas.

Yes, i will continue any webhosting panel related discussion and share ideas with you. It’s nice talking with someone with same problems, knowledge and experience like i have. I thing, that only open discussion and knowledge sharing can help to build the best conprol panel and at the end we all will profit from this.

I agree. I have webhosting company since 1997 and solve this the same time :slight_smile: I thing if the RAM will cont 10$/GB, we can isolate webservers one each for one other. If the ipv6 will be here we can build VPS for each virtual. When perchild module in apache will be working, we will open champagne bottle and will have time to solve other things :slight_smile:

Thanks for replies and thanks for understand my bad english :slight_smile:

Martin

I want to always disable system, exec and others. I thing open is not need to disable with safe_mode and open_basedir. If it will broke some application, user can buy VPS account. I thing, that good app don’t need exec something and if yes and can be trusted, we can set safe_mode_exec_dir

The problem here is more convenience than security. I can imagine the tickets we’d get opened regarding “interworx doesn’t support php!!!” or “interworx php broken!!!”. It sounds dumb, but we deal with many such issues and I’d draw the line here between security / convenience. I’d be happy to know how others using surepanel like it when you release. We had toyed (and still toy) with having a differnet IWorx-CP version that would address some of these issues but as of yet we’re focusing on the core product.

Also, saying “a good app doesn’t exec something” will rule out many apps and I disagree with the premise that good apps don’t exec things. Either way, convenience is being traded for security, and that’s ok, but at some point it becomes unmanagable.

No sticky. If user write files with FTP, it is set in ftp config (user:httpd/0640). If user want to allow webapp to write to some file/directory, he change this in controlpanel (do 0660). The only problem can be, that files written from webserver will be httpd:httpd (and 0640 or 0644 depend on umask) and the user cannot change (or read too) this files with FTP (must change perms in controlpanel) and user quotas not changes.

Indeed, which really nullifies the utility since you still end up with httpd/httpd files. You may try sticky bits to enforce this but as I said, they are often overridden.

How ? If webserver don’t have write access ?

In the previous 0660 case above you mention the webserver has write access. As does it in the case where the webserver creates the file and the file is 0640 or 0660 etc.

I cannot have safe_mode on in siterorx, because scripts are owned by user:user and safe mode needs to be owned by webserver (or webserver group). Or i missed something ?

You missed someting. safe_mode uses the uid of the script (i.e. the script owner) as a base value and not the SuexecUserGroup or the owner/group of Apache. So a SiteWorx account with a PHP script with cwells:clwells ownership can be run in safe_mode and can only read/write scripts owned by cwells.

And your suexec scripts acted as other users then webserver ?

Yes, but it doesn’t really matter since I can exec “cat” from PHP and read any file I like that is grouped to apache. You mentioned that you were going to turn off ‘exec’ from PHP which would thwart this but again the security/convenience tradeoff comes up.

Regarding suexec though, what user/group are you using for suexec? user:user? I wasn’t aware that suexec worked with a SuexecUserGroup of user:user when the script is owned by user:httpd.

Chris

The Apache docs on that last suexec point are conflicting so I’m curious to know if it works Martin.

From the Apache suexec page:

http://httpd.apache.org/docs/suexec.html

  1. Is the target user/group the same as the program’s user/group?
Is the user the owner of the file? 

Chris

All I can say is:

  • We were aware of this problem on our box
  • One of our users poked around and underscored all the possible scenarios
  • We used some things mukchar mentioned
  • Ultimately we wound up in the same spot Chris mentions. Some stuff breaks. We can fix the problem 80%, but not 100%. That’s just the way it is.

We keep GID’s set for safe mode w/ GIDs using setgid and stickey, and it works, but we only do it with sites I administer :slight_smile: The users would break this. I thought about adding an option to change ownership and permissions on configuration files so the web server can read them but not the world, but most users wouldn’t keep up. Our key sites are protected.

Either way, what it comes down to is making things a pain. The more time it takes/harder it is for someone to break security the better. Completely solving this problem isn’t going to happen with any shared hosting control panel. There is always some scenario that comes up. At the end of the day, as Chris enudes to, the inconvenience of the solutions outweights the inconvenience of a recover after a security breach given the low probability of one occuring.

BTW, (and I know Chris already said it) You can turn on safe_mode and optionally safe_mode_gid without any problems while you are using InterWorx. We did it server-wide with 0 problems. open_basedir didn’t cause any problems either.

Hello,

Just for info with nodeworx you easily can define a open_basedir for all new account created.

Just edit the file vhost-base.conf

vi /home/interworx/etc/vhost-base.conf

then add somethink like this

php_admin_value open_basedir “.:<<WEBROOT>>:…/…<<WEBROOT>>:/usr/share/pear/”

not sure if …/…<<WEBROOT>> works fine but I try allow access anywhere in the /home/account/ rather than only /home/account/domainename/html

Also about

I want to always disable system, exec and others. I thing open is not need to disable with safe_mode and open_basedir.

We’d tried to disable system and exec by setting up in php.ini the

disable_functions = system, exec

But we really had a lot of complaint from our users that they had a lot of pbm with their scripts. In this case they always tell you something like “hello I’ve a script that ran on an other webhoster but not with you, bla bla bla…” so we return back to a less secure option.

About the save_mod we did use it, and it worked fine on nodeworx environnment.

I think that with open_basedir, some chmod of dangerous unix command (wget, cat, ls, lynx, etc), save_mod on you not have a lot of pbms and your customer are enjoyed

Something that may be also good is to create a /tmp partition mounted with noexec option and ln var/tmp to this

So for me Interworx are on the good way (not telling you are not)

Pascal