Security Issue when running console Apply Configuration

[hsauerbach]

We are running Access Control for security on all our servers. When we make changes to nagios and attempt to run Apply Configuration we always get errors -- See attached file.

[dwhitfield]

We don't support any system hardening other than taking it offline, and using SSH and SSL.

That said, this looks to me like you didn't set a max_attempts, check_interval, retry_interval, or notification interval for '/home Disk'. Can you send a screenshot of where you set these up in the CCM?

I would suggest using service templates so defaults for these automatically get applied.

[hsauerbach]

Doctor,

We can not shutdown Access Control, so doesn't that mean the Nagios is unusable is a secure Environment? What happens if we do everything manually using /usr/local/nasiosxi/scripts to apply configurations and other product updates? Will that work, if not what suggestion do you have to work around the security issue?

Thanks

[dwhitfield]

We can not shutdown Access Control, so doesn't that mean the Nagios is unusable is a secure Environment?

So, this is probably mostly bad news, but I do want to start with some good news. If you take a look at https://www.nagios.com/roadmaps/ you'll see that "security improvements" are on the roadmap for 5.5. The first follow-up to that is not really bad news, but I have very little idea when 5.5 will actually be out. I suspect it will be out in 2017, but I'm not going to venture anything more specific than that. Now, for the first piece of probably bad news. Based on the rest of this section (before the next quote block), I really don't know what "security improvements" means.

I can tell you that what financial institutions do is just set up SELinux and such themselves. It's possible they hire consultants such as http://everwatch.global/about (we have other partners, but they are very prominent). Our prices are so competitive that even with the cost of consultants, we're likely to come ahead of our competitors when it comes to bottom line. XI certainly can be made to work in such an environment, but it's not something that our support team handles.

It's a bit old, but we've sent people http://chrislaskey.com/blog/602 in the past. Most recently, developing for SE Linux came up on March 30 and was again rejected at the earliest stage. So early, in fact, that an official feature request was not even created.

I know SE Linux is not ACL, but SE Linux is what comes up the most often and since I have a date I can point to with that, I'm using that as a stand-in for additional security measures.

What happens if we do everything manually using /usr/local/nasiosxi/scripts to apply configurations and other product updates? Will that work, if not what suggestion do you have to work around the security issue?

When you say product updates, do you mean just updating the system? I *always* suggest people do this manually so php/apache do not get in the way: https://assets.nagios.com/downloads/nag ... nstall.pdf Any sort of wizard/check modifications will be overwritten on upgrade, so if you make custom changes, make sure you create those as separate files.

Applying the configuration via the command line should work just fine. I'm a little concerned with the "everything" part of your statement. It is possible to manually configure files, but they will not be visible in the CCM: https://assets.nagios.com/downloads/nag ... ios-XI.pdf

The API, while command line, still is database driven (it is a CCM API), so I don't think that's really going to get you where you want to go.

[hsauerbach]

Doctor,

Thanks for the update very interesting. It looks like we have a work around for the Access Control issue to execute Apply Configuration.

Thanks

[dwhitfield]

Each license comes with the ability to install three nodes: production, testing, and backup. If I were you, I'd grab one of our ovas (https://www.nagios.com/downloads/nagios ... downloads/) and have that in a completely pristine environment devoid of the security measures. Obviously, no data goes there, but you can add dummy hosts/services and see how things are supposed to work. I think that information will prove useful in locking things down appropriately.

Certainly, if there's a specific security issue (passwords in the clear, etc.), we'd like to know about that and I can file a bug report.

The big stuff, like "make it work with SELinux (or ACL)" is just not going to happen right now. However, if there are some steps we can take to make setting up SELinux context easier for people, again, we'd like to know.