I am using smartFTP and so I guess it is similar with other FTP clients that show the server directory.
I can access many of the directories that I thought that I would be restricted from.
After transferring the cchon file from the boot, I tried to delete it but it did not allow it.
The file system.map-2.6 was also transferred but again I couldn't delete it, so it does not seem to be a big problem.
What I was thinking is - can a server savvy person take one of these available files ( like system.map) and derive a client list from it ?
From the Home directory all the servers can be seen - so I assume that means that any server owner on my system can see how many other servers there are ?
Does any of this bother those of you that run a commercial hosting server ?<br><br>Post edited by: Davvit, at: 2009/05/21 23:24
yes it bothers me since any malicious user doesn't have to guess usernames anymore. That's 50% of the work. So I disabled browsing over ftp and only give ssh access to trusted users.
<div class='quote'>What I was thinking is - can a server savvy person take one of these available files ( like system.map) and derive a client list from it ?</div>
Maybe, but it's actually much easier to obtain the user list than that :-)
The /etc/passwd is (and has to be) world readable. It has a list of all users in it (passwords are stored in the more restrictive /etc/shadow file).
Whether FTP users are prevented from browsing or not, any user can upload a two line bash script that would output the passwd file -- giving them the usernames, description, home directory, and shell of all the users on the system :-)
So my thoughts there are:
1. Taking on a client is giving them some amount of trust
2. Security may need to lie elsewhere, knowing that any web customer can obtain a user list with a small amount of effort. That's where mandating more secure passwords comes in. That makes it difficult to guess -- and you can use various tools to block hosts that continually guess at user passwords.
Just some thoughts!
-Eric
<div class='quote'>can a server savvy person take one of these available files</div>
As Eric mentioned, a server savvy person can do that even if they don't have filesystem access via FTP or ssh. If you allow them to run applications, at all, under Apache, they have this ability. If you allow them to use server-side includes, they (probably, based on configuration) have this ability. If they have the ability to use mail forwarding features of procmail, they have this ability. If we were to pause and think really hard, I'm sure we could come up with a dozen other ways.
The UNIX security model has existed mostly unchanged for 30+ years. The files that contain actually sensitive information (usernames are not sensitive; you know my username on Virtualmin.com if you've ever gotten an email from me) are only accessible to the users that need access; either root; or the owner and root; or the group, owner and root.
--
Check out the forum guidelines!
I got this shell script and uploaded this to a user account.. it was possible to get the content of .usermin/inbox.imap from other users which contains the client password.
That's a major breach of security, so I guess security rules can never be enough.
The average client doesn't know how or is not interested in breaking in, but you'll never know when the wrong person buys your product.
<div class='quote'>I got this shell script and uploaded this to a user account.. it was possible to get the content of .usermin/inbox.imap from other users which contains the client password.</div>
This shouldn't be possible. Homes should be 750, which would completely prevent this from happening.
But, .usermin should have it's own permissions in place. That's a serious bug in its own right. I'll ask Jamie to check out this thread. There's no reason for .usermin to be anything other than 750 or lower.
--
Check out the forum guidelines!
Yes, this is a bug .. there is a case where the .usermin directory can end up world-readable. although only users from the same domain would be able to see it, as the domain's home is not world-readable. I'll fix this in the next Usermin and Virtualmin releases.
--
Check out the forum guidelines!
I am glad that this UserMin bug has been noted and will get fixed.
Will that prevent Ronald's shell script from lifting the passwords ?
Also - Is that shell script only harmful (in the wrong hands) against a Webmin/Virtualmin install, or is it equally bad on a WMS/Cpanel install on a unix machine ?
<div class='quote'>Also - Is that shell script only harmful (in the wrong hands) against a Webmin/Virtualmin install, or is it equally bad on a WMS/Cpanel install on a unix machine ?</div>
It was a very specific script with a very specific purpose, and it won't work on most Virtualmin installations. Most Virtualmin installations have /home/domain set to 750, which would prevent other users from ever getting near the .usermin directory (assuming you're using suexec).
--
Check out the forum guidelines!