monit default value includes hardcoded password
elseym opened this issue · comments
is there any specific reason to include a hardcoded password in the default for the monit configuration?
No, this is a dumb solution, but it is not accessible from the outside and the password is required. Any idea how we can make this better?
Please explain what is so dumb about it. As you pointed out, it is not accessible from the outside. It is merely required for the http server to start. It won't start without specifying the password.
The web server is not accessible from outside, only from localhost. Only root can query monit. If you call, say monit report as a non-root user it will fail. And at no point it is necessary to actually input the password by root.
It is possible to start monit without the web server and therefore without the need to specify a password there. However this cripples monit in its functionality because the command line client relies on the webserver.
The way it is now this is not unsafer than say the rspamd unix socket.
I know the sight of a hard coded open password is a bit irritating, but really, there is absolutely no need for a custom password there. It is completely irrelevant.
Speaking of rspamd: The rspamd we use has not one but two default passwords, that are unchanged. They are q1 and q2 respectively. Those are of much greater importance because users can actually influence the rspamd daemon when specifying those passwords with rspamc. That way they can train rspamd with ham and spam messages.
I suppose I should have put something along the lines of "please ignore" as password there rather than a random password.
Sorry, didn't mean to criticize your solution there. My comment is meant to say the same thing you mentioned. I'm not aware of a better solution.
@r-raymond no harm done :)
This all being said, if someone wants to have an easier to remember password there because they do actually want to access the web interface (say via SSH port forwarding) I suppose it wouldn't do any harm to make it configurable. Is this your usecase @elseym ? I'm all for adding more convenience. I just wanted to make clear that there is no security related reason against having it hard coded. That is unless I have grossly missed something.
@phdoerfler thanks for explaining the how and why.
i have not used the monit component of this module yet. from a general perspective, i find it problematic that right now, by just enabling monitoring, a pre-set admin password will be configured for the system (or any part of it). i'd rather have anything account- or access-related being set explicitly. (you can call it security awareness or paranoia 😄)
for this instance, i'd suggest assigning the literal monit configuration to the example parameter of the option and not to the default. the user would have to copy-paste the example to their configuration and adapt it accordingly. they'd explicitly opt-in.
one could also expose a new monitoring.credentials option and use it to compose the config string.
if, on the other hand, the most important thing here is convenience and the password remains in the default config, then at least it should be made very clear that it, if left unchanged, poses a security risk on certain systems / configurations.
@elseym I assume you are talking about port forwarding via sshd or other means such as netcat or socat by ordinary users. Users that already have full shell access to your system. Users that can fill up your hard drive, start a fork bomb, see what processes are running and so on. Yes these users could, if you do not disallow it, manage to access monit's webserver and see what services are running on the server. I assume they could also unmonitor services which if I remember correctly triggers an email to the alert address specified.
You should never give users that you do not trust full shell access to your server in the first place. If you do have users that you do not trust and you would like to use monit you can change the suggested default config completely. There is no need to use the config provided. Please note that /nix/store is world readable. The monit manual does however specify that monit's configuration file must be readable by no one else other than the current user.
The intention behind the default config is for people who use this as their own personal webserver and they are the only ones with a user account. I assume that this is the majority of users of NMS. Since without an ssh login it is impossible to access monit's web interface there is no drawback of having a pre-set password.
Please note that the entire monit module is opt-in and allows modification. It is not enabled by default.
from @phdoerfler's explanation (thank you) i understand that we share a very similar view on the purpose of this module: it is an opinionated module providing a simple interface for a robust mail server setup. that is one of the main reasons i like this project and the work @r-raymond and other contributors have put into this.
for this issue, i'd rather not resort to speculative discussions about the likelihood of a system being compromised, the probability of malicious users having access, or similar topics. nor do i want to talk about details on how nix works.
instead i'd like to point out that a piece of code, which is designed for ease-of-use and therefore provides an affordance to enable certain features with just one switch (e.g. monitoring.enable), should not silently install a publicly known predefined user credential without explicitly warning the user about it or requiring the user to explicitly specify said credential: the designers of this module just cannot know how the target system (i.e. the system where SNM is being installed) is configured, security-wise. security configuration should be mandatory rather than implicitly set by default.
(for disproportionally big security-related default configuration f**k-ups, you could look at things like the current "GitHub DDoS Incident" or "The MongoDB Hack" from some time ago)
TL;DR: how about we make the credentials non-default and configurable? 🙂
as soon as i have some time, i'll be happy to create a pr implementing one of the approaches mentioned above, which i'm sure will be subject to a discussion on it's own before getting rejected or accepted. 😉
@phdoerfler @elseym I understand the sentiments of both positions. I like secure by default things, and I hate making user specify unnecessary things. I think the possibilities we have are
- Warn the user of this fact if he enables monit
- Make the user specify a password that he can't use in any way later
- Use a random password
- ?
All of these have pros and cons (except for ? I guess). If you come up with any idea (and or PR) for this I'm happy to discuss options.
@elseym @r-raymond I don't mean to offend anyone (I hope this doesn't need saying) and I am grateful for your input on the subject. Having this said please allow me to be frank.
I think you are all overthinking this. The name of the game is a "Simple Nixos Mailserver". If you are willing to invest considerable time finding a solution that is truly secure, be my guest. I won't and I will now unsubscribe from this issue. I believe I have made my position clear and I don't think we can have a discussion about IT security ignoring crucial "details" such as the workings of nix because nix is by design public. There is an old and length discussion about this already: NixOS/nix#8.
When you read through this you may find that it is a non trivial task. I wish you all the best and a good day.