The email transport on the server was working fine as all other emails (from system, etc.) were being sent without issue. What was most bothersome was there were no log files indicating that the hand off of the emails had any issue or were stopped.
The site I tested this with was chrooted, which was apparently the problem. When I turned off the chroot on the site, the issue disappeared.
Can anyone help me understand why this is? In other control panels on boxes I operate, chrooting web spaces for WordPress use has never stopped email from being used from them. Is something set up differently for the chroot process done in Virtualmin?
Also, once I remove the chroot from a site, the chroot directory for that site is not removed by Virtualmin. Shouldnāt it be?
I donāt think it is the responsibility of Virtualmin to tidy up after you have just decided to do something outside. I would say clear up your own mess. Even more so if you have implemented something at the behest of some other dubious app.
Virtualmin does have an option to chroot a user so therefor i think the op has a valid point however i would only use a chroot on a user that has and will use shell access and also use the correct utilities to add whatever the sys admin deems fit. As Joe pointed out chroot has not much effect to a web user as they have limited access to the system. With regard to cleaning up afterwards there may be files that have been added to the jail that may be required after the jail shell is removed so i guess vmās idea of leaving the jail intact is valid, to then allow the user to review and copy or delete as required
Sort of understand that - but if the user has added something just because "it was needed by something added external to Virtualmin and not required by virtualmin then it is up to the user to clean up the mess. If I decide to add an application that ārequiresā the server to run (for example: Go) then I donāt expect Virtualmin to manage it. Just as at the moment it does not do a very good job of managing nginx (it is not very good at cleaning up .conf files) but it does help provide some tools.
In this case the decision to chroot a user seems like one based on external poor advice. not on use of Virtualmin. A decision that led to a long convoluted topic trying to find out what the user had done to break the original basinc install.
Virtualmin offers the ability to chroot in the OPās instance chroot was added in the thought it would make the server more secure. This is not a case of adding stuff that an app needs to run ā¦ to date I have never come across an app that requires a chroot/jailkit. So if Virtualmin offers chroot and the ability to remove it perhaps it should tidy up or ask if the chroot/jailed structure is to be removed or left, so the user can review changes to that environment
Perhaps (as it seems it is not needed for the straightforward use of Virtualmin its use should come with a big red warning message then another on the way out.
The chroot (jail) is installed through the Virtualmin interface.
So itās not something I
Your statement is akin to saying that if one creates a virtual server under Virtualmin and when itās no longer needed, then one should have to manually go in and remove it.
Doesnāt that logic bypass the entire reason for control panels and GUIs altogether?
Jim, Iād agree, but my experience is that a customer comes along who needs (or THINKS they need) SSH access and at that point we donāt know where it could go from there. Or a web space becomes hacked after the userās credentials are acquired and thereās access by a bad player. Iāve been using another control panel since about 2003 on a number of boxes with chroot capability and was advised to use it and have been since back then. I was told then that it is one of various ways to help keep sites secure.
I explained why it didnāt work in that other thread.
You need to add anything you want your chrooted user to be able to use to the jail. To use sendmail, you need to add that command and its libraries to the jail, either using the jk_cp command or adding it to the config file for the jail being created for your users (there are several included jail configs, we default to a quite limited one, for security reasons).
This is true of any use of a jail, regardless of control panel being used to manage things. A chrooted user only sees what you put in their chroot. If you want them to use PHP, you gotta give them php (and maybe the specific extra versions they need, if any). If you want them to send mail, youāve gotta give them sendmail. As I said, there are some defaults included with Jailkit, or you can make your own and tell Virtualmin to use it.
The point of a chroot is to restrict what the user can and canāt see and do. Itās quite restrictive by default (and by necessityā¦itās not all that hard to accidentally give users the ability to escape the chroot).
Which sort of explains why it should come with a big red warning. along with busting the myth about added security - yes if you really know what you are playing at and not at the whim of some app.
a domain owner does not really need access via ssh really with there priv level they can do nothing to the system barr look at directories they have privs to ā¦ This is the point of webmin/virtualmin it negates the need for ssh access as webmin/virtualmin has
a File manager that can cover most file operations (upload/download/new/delete + more)
a terminal that gives the same access as ssh
a lot of things a domain owner would need wrapped up in the virtualmin gui
so what do you think the user would benefit from having raw ssh access ?
As the virtualmin terminal is that good, to the point I have not broken it yet, On my own server I am thinking of removing native ssh access and using just the virtualmin terminal if the user ever wants to use it. I have found most domain owners seem to use the file manager and the virtualmin menuing system to edit what they need and very seldom use the terminal.
It may be true other panels may ānurse maidā a jail by adding virtually everything to the jailed user but perhaps that is not required and the sys admin (i.e you) should have a total say what system files are added to the jail to avoid possible break outs of the jail.
maybe this is just a way of an new way of sys admin to you but it does work, but I guess each to their own
No. The distro had nothing to do with defining the jail configurations (though I guess they could, jails are not a thing most people care about). The upstream jailkit source provides them (and as far as I know, theyāre mostly unchanged by the distros that do package jailkit, and our package for RPM-based distros does not alter the jailsā¦we used to fix a bug in one of the jails from upstream, but itās now been fixed upstream, and we no longer customize it).
There isnāt any judgment happening at the distros. They donāt care. Itās just another package to them, and itās a very rarely used package in most contexts; you wonāt find any Debian/Ubuntu/RHEL core documentation about Jailkit, because jails are not very useful, itās just a thing people in the hosting world like.
But, the idea is that youāll configure the jail to suit your needs or the needs of your users, and with the commands youāre comfortable with them having. There are a handful of predefined jail configurations, and you can create as many of your own as you want. I guess we should spend more time on either documenting that or making the default jail do the usual things people expect to be able to do when they ssh in (but that negates most of the already small security benefit of a chroot jail).
This is getting me closer to what I have been trying to figure out, Joe.
Sorry about not knowing exactly what questions to ask and thanks for your patience as I grope through this topic. What I am understanding better now is that chroot is set up differently amongst different systems. In my naivety I thought of it as a single function that worked the same across different platforms.
I would like to be able to use mail from sites using chroot in Virtualmin. So it appears I need to research a little more about exactly how I go about doing that in the Virtualmin environment. That was what I was hoping to learn using this forum thread.
What Iāve learned so far is that chrooting is like believing in different religions - everyone thinks theirs is the right one. Beliefs aside, Iām gathering that chroot can be considered a security measure, but that itās a basic and limited one. It looks like it can help to isolate processes and limit the potential impact of a security breach. However, it is not foolproof and can be circumvented under certain conditions, especially if the process running inside the chroot jail is running with root privileges. Iāve read that chroot is best used as one layer in a multi-layered security approach. It can add an extra hurdle for an attacker to overcome, but it should not be the only protection mechanism in place.
Sounds like I need to know more about
Joe, you said
so Iām curious how I would find out more about that to be able to add to it.
We use Jailkit for Jail creation and management (probably most others do, too, except maybe cPanel who have a lot of their own in-house tools and custom build everything), so the Jailkit site is a good place to start: Jailkit - chroot jail utilities
Last I checked Debian (and Ubuntu) did not build Jailkit with capabilities, and so they are more likely to be dangerous than on RPM-based distros, where we provide the package and it has capabilities enabled. The chroot is created with full root privileges on those distros, and if exploited at that stage, it would potentially provide root access to the system, not merely a chroot escape (having it build to use capabilities means it only has the ability to create a chroot and maybe one other privilege I canāt recall, so itās less of a threat, though still potentially problematic). Soā¦I kinda think using chroot jails on those distros is negative for security. The likelihood of an exploit is probably pretty small, if you are careful about what you put in your jail(s) and what permissions they have. Itās an old codebase, and has had lots of time to become well-understood. I recommend reading and understanding this specific page, in particular, Jailkit - chroot jail utilities before using jails.
Since we started moving into WordPress (kicking and screaming I might add) about 15-20 years ago itās now 98% of the sites we build and host so itās important website forms work.
My experience since 2003 has been with DirectAdmin and recently going all Debian on those boxes as well as a couple of recent Virtualmin boxes. In DirectAdminās āJailā (my ONLY experience using āJailā functionality) WordPress sites do not encounter any issue with sending mail through their forms.
Thanks to your input, Joe, Iāve been reading the suggested info on https://olivier.sessink.nl/jailkit and really understand now that I had little idea overall of Jailkit!
Of course, I have no idea for sure what āflavorā of Jailkit DirectAdmin is using. But even looking through Oliverās material I donāt see where itās directly explained how to get mail OUT of the Jail. Unless the part where he explains how to let it IN does both. I find that piece confusing.
If anyone can help me understand better how to allow sending mail from the Virtualmin āJailā that would be a great help.
To send mail using the sendmail command, you need to add the sendmail command to the jail, either via jk_cp (for one user jail) or by adding it to the jail configuration file (which will add it to future created jails).
Ok, bear with me while I try to wrap my brain around this - does this mean sending the user out of the jail to use sendmail or copying all of sendmail in its directory structure into the jail?
Is it possible that without the sendmail being set up correctly, the condition could occur that thereād be no error or anything else obvious from within the jail when one tried sending mail from in the jail?
It means literally using the jk_cp command to copy one command (sendmail) into the jail. The jk_cp command copies all library dependencies into the jail, as well.
I donāt know what this means. But, there was an error when you tried to send mail from within the jail; it was a command not found error, and it was because sendmail was not in the jail.
