I started setting up a Virtualmin install as the features, etc look good.
However I doubt I can continue as although I am no security expert I did some basic tests and it seems that things are quite insecure.
For example I created a new virtual server and tried this in a php script:
$s = file_get_contents("/etc/httpd/conf/httpd.conf"); echo $s;
and yes it echos httpd.conf with everyone's virtualhost settings, etc, etc. I haven't tried any other files but that is enough to wonder what else a user could do on the system. Sure I could muck with all the permissions on files myself, but really thought a shared hosting system like Virtualmin would have all that sorted. Its the same on the Pro and GPL versions.
So now I don't think I can use it and are a bit disappointed because I have already spent time setting things up, assuming that Virtualmin would have quite basic security requirements like this in place.
Am I seeing things correctly? I would really like to stay if I could - what should I do?
This is *NOT* a security issue at all. How could any virtual host directives be a security breech in the first place?
Second httpd.conf has to be world readable or no ones site could be used since each site is configured to run as its owners ID/GID.
a system is only as secure as the sys admin makes it no matter what control panel you put on your box.
normally files are 644 and directories are 750
Could always rely on MS IIS server if you cant trust linux :)
and all logs are kept under /home/domain/logs not under /etc/apache(httpd)
you need to see this software as a way to manage your box. it will in a GUI way help you to secure the box instead of using the command line.
who is to say my httpd.conf is under /etc? First one needs to locate the file before able to extract it and post it in a forum.
the OS is 'opening to share', you can do webhosting with only centos (or debian) on it :)
knowing what's on the box makes it slightly more convenient for malicious people as they know where /what to look for, but then they still can't get in as you have passwords I hope
It is a security issue as it makes a lot more internal information about settings available than needs to be.
httpd.conf was just one example - What about all the log files under /etc/httpd/logs? - they are all readable as well - who knows what info will be given away in there. What about the start up scripts? I'm sure there are others.
As I said I am newbie to Virtualmin, and I am really surprised that these things have not been addressed, as obviously a lot of great work has been done on Virtualmin and seems that these issues could be dealt with quite quickly by those with the know-how.
(By the way httpd.conf can have its permissions changed to 0600 and things still seem to work without having it readable by all users.)
In my opinion it is Virtualmin that is opening the box up to share, so it should be the one that deals with making it as secure as it can.
I am coming at this from a business point of view. If any of my business users were on a Virtualmin box and then ran the php which shows all theirs and others settings, and then say posted the results on my forum then I'm sure most serious business users would run away very quickly.
I would like to see Virtualmin progress. I am posting this as a serious concern that we and other business users have. Hopefully Joe, Jamie, etc will also provide some feedback during the week.
An easy way would be to restrict the php.ini for the specific domain with the open_basedir directive in /home/yourdomain/etc/php5/php.ini
open_basedir = /home/yourdomain/
<a href='http://de3.php.net/manual/en/features.safe-mode.php#ini.open-basedir' target='_blank'>http://de3.php.net/manual/en/features.safe-mode.php#ini.open-basedir</a>
for security purposes your could also deactivate some functions with the disable_functions directive.
<a href='http://de3.php.net/manual/en/features.safe-mode.php#ini.disable-functions' target='_blank'>http://de3.php.net/manual/en/features.safe-mode.php#ini.disable-function...
This has been discussed, quite frequently, in the past here in the forums. What you consider insecure is merely the way UNIX/Linux works. That which is sensitive is not readable by Apache, and what you're considering security holes are present on every UNIX/Linux system. 30 years of UNIX history tells me that it is not a problem. Your experiences may be different, and that's OK...but if you don't trust Linux, you shouldn't trust us, either, because Jamie and I are thoroughly steeped in the UNIX tradition. We like it, and we think it's just the right way to build and OS. If you'd prefer to move your sites to a more secure OS, like, say, Windows, let me know, and we'll issue a refund for your Virtualmin Professional purchase. ;-)
In short the alternatives are far less appealing. chroot is one such option (if you don't want to go for that rock solid Windows server experience), but it was never intended to be a security tool, and it removes a couple of real security protections in exchange for a false sense of security. The other is total virtualization--which is quite resource intensive. We think it's a great idea, when appropriate, and we've built a new product to manage virtualized systems. But it doesn't take the place of a virtual hosting management system--it merely puts another layer on top. And, of course, if you don't use suexec (which is the default under Virtualmin, if you've installed it using our install script, and always easy to enable) you <i>will</i> have some security concerns.
Check out the forum guidelines!
Yes I know it comes about from the way the permissions system works on Unix/Linux.
I think if Virtualmin provided some option whereby it did a quick permissions audit and closed off read access to all users except where needed, would go along way (eg httpd.conf doesn't need to be readable by everyone - also by the way I found that rc.local startup script in your pro ami is writable by everyone). I could troll my way through all the files, but I don't know what could be the side-effects of changing permissions - I think such a job would be better done and tested by experts like yourselves.
Joe, Iam trying to provide some real world feedback from my and my customer's perspective - I am hoping that it could be used to enhance Virtualmin - throwing in the towel and going to Windows is not the answer.
Total virtualization has its benefits, but obviously be better to have a solution for simple shared web hosting that doesn't need that extra overhead. As I said, I think a script which audits the permissions and suggests and makes changes would go a long way.
Re chroot in most cases I think not allowing shell access is the best, but getting php fastcgi running inside a chroot jail could be the ultimate answer to the issues I raised here - an article at http://www.seaoffire.net/fcgi-faq.html describes how to do it in detail - maybe something for the future?
Re open_basedir, etc, I thought when running as fastcgi everyone got a php.ini and then couldn't they just override these themselves?
<div class='quote'>As I said, I think a script which audits the permissions and suggests and makes changes would go a long way.</div>
This assumes we think there should be changes from the default shipped by Debian or Red Hat, and, in general, we don't. ;-)
I'm of the long-held opinion that most "hardening" scripts are mere hand-waving and blowing smoke. I don't want to be among those snake oil salesmen who sell empty promises in the guise of security.
<div class='quote'>Re chroot in most cases I think not allowing shell access is the best, but getting php fastcgi running inside a chroot jail could be the ultimate answer to the issues I raised here - an article at http://www.seaoffire.net/fcgi-faq.html describes how to do it in detail - maybe something for the future?</div>
As I mentioned, chroot simply was not designed to be a security tool--using it as a security tool is, once again, a bit of smoke and mirrors. It's not improving security. It's hiding a few bits of detail about the system to casual investigation...but also opening up potential serious security issues (like the fact that the chrooting has to be initiated by a root-level user...so if it is exploited, it is far more likely to be a root-level exploit, which means you lose everything in then event of a security hole, rather than just one virtual server).
I think you're misinterpreting my brief answers: My point is not that security doesn't matter to us, or that it shouldn't matter to you. We are deeply concerned about security of Virtualmin, Webmin, Usermin, and the services that our products manage.
It's that what has been presented as security so often in the web hosting world, is in fact one or both of the following:
Dangerous by design (like using chroot as a security tool)
A pointless waste of time (like fretting over a user having read access to passwd or httpd.conf)
The things that contain sensitive information should be locked down--and they pretty much are, by default, on a RHEL/CentOS or Debian system.
I don't want you to think we're merely waving off security as an unimportant concern. We're not. It's that we're trying to prevent our customers (whom we like, and wish the absolute <i>best</i> in their experience with our software and the servers they manage) from either making dangerous mistakes (like thinking chroot is a security feature, when it is just as likely to be a security hole, and an extremely serious one) or wasting their time fretting over things that cannot be prevented in a shared hosting environment (e.g. if you give me the ability to upload arbitrary files to a web hosting account on pretty much any UNIX/Linux system, regardless of whether I have a shell, and I can get the contents of /etc/passwd--no matter what you do to PHP or fcgi...but, that's OK, because UNIX was designed that way, and it's not a security issue.../etc/shadow would be a big problem, but I can't get that, even with a shell).
I'm not advocating the use of safe mode in PHP or basedir. I'm not opposed to them, per se, but I don't consider them mandatory and I don't use them on the systems I manage, including those with shared hosting users. (Though, the less trusted your users are, obviously, the less privileges they should have. basedir might be a good compromise for many classes of nosey but not very UNIX literate users...it won't stop those users that are literate, though.)
Check out the forum guidelines!
I don't see what is wrong with restricting read access to the settings, log files, etc - it will definitely divulge less information about what is inside your box, so its not just blowing smoke, its actually doing something in the right direction.
Just because Debian and Red Hat ship it like that doesn't mean it is still the best way to leave it - especially after you have added a shared hosting panel, which by its very nature opens it up to unknown users. Its the control panel that is making it easier to bring these unknown users into your box, therefore would expect it would be the control panel which would try to remove permission from things not needed by these extra users, over and above what the distribution's default does.
Yes I see your point re chroot - I'm not familiar with the ins and outs but as you say if one could conceivably get root access that is scary...but seems many are using them.
<div class='quote'>I don't see what is wrong with restricting read access to the settings, log files, etc - it will definitely divulge less information about what is inside your box, so its not just blowing smoke, its actually doing something in the right direction.</div>
We're still talking past one another.
How do you safely restrict said access?
chroot is not safe, and permissions won't do it (generally.../etc/passwd, for example, has to be world readable or the system will break in numerous catastrophic ways).
If security is a major concern--for example you really are allowing wholly untrusted and anonymous users to run arbitrary applications on your system (which sounds really dangerous to me...you should at least know who you're dealing with, so you can disable their account, and optionally make use of legal remedies), then suexec is a good choice. Virtualmin loses a few features in a suexec-enabled system, and you have to add a few rules to the policy to even allow scripts to execute in /home, but mostly it'll work (I used to manage a large Virtualmin deployment for an Open Source projects hosting site that used suexec...the users weren't troublesome, but they were somewhat anonymous, so we went to a few extra lengths to insure they couldn't cause any trouble).
But, let's get specific. We're both doing a lot of handwaving about what's secure and what's not secure, and that's not very productive. ;-)
What files are you really worried about? I'll see if I can provide some guidance on how to protect those files, or reassure you about why they are not a concern. (The Apache logs, for example...I'm not sure why these would be a concern...everything useful ought to be logging to the users own log directories in a virtual hosting environment...very little would be going to the /var log files, and certainly nothing sensitive, I would think? If so, that's a configuration issue we'd want to address on your system.)
Check out the forum guidelines!
Oops. I just noticed that I said "suexec" multiple times when I meant "SELinux". That'll teach me to post before I have my tea in the morning.
Check out the forum guidelines!
Okay thanks. I'm not a super Linux admin by any means, I just started by trying httpd.conf because I knew that was where all the virtual sites config was being set, and was surprised that a user could read it, and guess lost a bit of confidence wondering what else could the user do. I was also surprised by the initial nothing to worry about - get over it or go to windows responses, when I was just trying to solve a problem - perception or not.
So I guess any file that has user ids, config, etc is what I would be concerned about - I don't know what they all are, but other more experienced users on the system could find them. I mean things like all the .conf files under /etc and sub directories - do these all need to be readable by everyone? There are also many logs under /var/log readable - eg yum.log tells everyone all you install modules and patches. I don't think anyone could be certain what internal info will eventually turn up in any of these logs could they?
Re <div class='quote'>...allowing wholly untrusted and anonymous users to run arbitrary applications on your system (which sounds really dangerous to me...you should at least know who you're dealing with, so you can disable their account, and optionally make use of legal remedies)</div>
- allowing anonymous users being dangerous - that's what 99% of the shared hosting providers do isn't it?
Any advice including selinux in the context of Virtualmin would be good. As time permits I guess you could write it into a doc / wiki page that would assure other potential users of Virtualmin.
<div class='quote'>- allowing anonymous users being dangerous - that's what 99% of the shared hosting providers do isn't it?</div>
I wouldn't think so. How would you bill an anonymous user? Unless you're providing free hosting, I can't think of when you'd be dealing with anonymous users.
There's a huge difference between a paying customer, and an anonymous user. You have legal remedies in the event a paying customer uses your system for illicit purposes--particularly if you have reasonable terms of service that every customer must agree to. It's also easier to simply kick them off of your system and expect them to never return--if they cause trouble once, you decide to never work for/with them again, and you know who they are so you can add them to your own internal blacklist.
Again, depending on the level of the relationship you have with your customers--whether you know them personally, or they signed up via an online form and paid with PayPal and are thus semi-anonymous--you'll alter your policies and privileges to suit the situation. Virtualmin is targeted towards full-featured hosting, and wouldn't be a good fit (without some customization) for a free hosting service. Any full-featured shared hosting environment has an implicit level of trust that you're placing in your users. Even with all of the resource limit, quotas, etc. features that Virtualmin has, it'd be trivial for a user to shut down your system. DoS attacks for a user with any form of arbitrary executable access is extremely easy to achieve (a fork bomb can be written in any language, including some that would surprise you--if they have unrestricted .htaccess file capabilities, which seems to be extremely common, it's probably possible to launch a fork bomb in nearly any scripting language on the system, including shells).
Anyway, my definition of "anonymous user" is literally people you cannot identify, and thus could not send an angry letter via post or take to court to demand restitution in the event of abuse. Obviously, you probably won't be taking anyone to court...but anonymity is a requirement for people looking to get up to serious mischief. But the types of mischief most such users want to get up to is not related to the data on your system at all (though spammers do like valid email lists, and that's accessible on most shared hosting systems), it is instead related to usage of your resources for launching attacks, marshaling previously exploited resources (via an IRC bot, usually), or sending spam. These kinds of things are pretty easy to spot: An IRC bot process is obviously a cause for concern, a huge volume of mail from one virtual server, mass bandwidth usage outside of web/mail (possibly indicative of port scanning and DoS attacks on other hosts, among other things), etc.
<div class='quote'>Any advice including selinux in the context of Virtualmin would be good. As time permits I guess you could write it into a doc / wiki page that would assure other potential users of Virtualmin.</div>
This is something I'd like to spend some time on. Jamie actually implemented most of the pieces within Virtualmin itself to operate within a SELinux-enabled system ages ago (as long as a couple of limitations are already accepted as being unavoidable in such an environment), so it's really now just a matter of educating folks on what the trade-offs are and how things work in an SELinux-enabled hosting system. It's entirely possible to run with a pretty tight policy enabled...but SELinux is a really complicated beast and very few people understand it very well (I'm not one of the people that understands it well), and so it brings up a <i>lot</i> of "I get permission denied, even though I've triple checked permissions and tried every possible combination of permissions". Because it's an invisible layer above file permissions, it trips up everybody at least a few times, and that's a pretty frustrating thing.
If your business runs closer to the "anonymous" side of the spectrum, you might like to volunteer to be our guinea pig in this regard. Enable SELinux with the "targeted" policy, and see what breaks. Let us know, and we'll start working towards more comprehensive management of SELinux rules in Virtualmin. Since we've not had anyone really wanting SELinux enough to deal with the hassle, we have very little idea about what kinds of things remain to be done--as I mentioned, a big early deployment of Virtualmin used SELinux, and we addressed the problems we had there, but it was a pretty specific set of use patterns for all users (only a few apps were in use, for example), so I'm sure many other features won't work right off the bat.
Check out the forum guidelines!
Hey Joe thanks for your spiel on anonymous users. In context of what you say I guess I mean semi-anonymous users, but as far as how easy it is to sign up to many shared hosting providers in the context of the system then they are almost anonymous...who knows how they will use the private info...I'm not thinking just an attack from within the system, anyway if it was, too late after whats done is done...
Anyway I didn't mean that to be the main focus of this, as you said lets deal with specifics...what about the specifics I mentioned - could you provide some advice here or in a page in the doc? I think that will be a good start, without getting into potential SELinux hassles you mention.
Sorry for reviving an old thread but this is still an issue at the time of this writing (September 18, 2014). I'm using Ubuntu 14.04 and Virtualmin 4.10 GPL.
One can cover it up that it's an admin's job to cover these issues up but why not make Virtualmin cover these things up out-of-the-box? Everyone knows Virtualmin's general market: people who want to offer shared hosting services, so why not patch up that part of security?
I'm using Nginx with PHP-FPM and tried to enable the open_basedir option and the safe_mode option, to no avail. If I need to install Suhosin or some other variant, can someone please offer instructions to do so? Because I haven't been able to find anything so far.
Sorry for the rant. I hope this gets some attention to make Virtualmin perfect as it deserves to be!