cdienger wrote:Have you found these on new installs or are these upgrades? The permission on you machine are not matching the default permissions on my lab machines:
Hmm - that's a good point. All three of our XI machines (we have two prod and one dev) had the same / similar issues, and I believe all three originally had XI 5.2 or 5.3 installed but have been upgraded one or more times since original setup. (I joined this team after those servers had already been built, so I'm not sure when the issues first appeared.) Since all three had similar problems I thought it was from the installer / upgrader scripts but it could have been from the professional services engagement way back because I think the same person built all three.
If I perform a manual upgrade (from tarball download) on top of our now-fixed dev instance and the permissions issues reappear I'll report that to you.
Maybe I'm missing it, but that doc doesn't say anything about needing to access / change anything to do with the OS authentication config files in
/etc/openldap
The only place that "/etc" appears in that doc is
/etc/resolv.conf
If I understand it correct, when XI is using LDAP / AD for authentication that is completely independent of the OS. More to the point: an application running on a host should NOT be able to modify the underlying OS authentication mechanism(s)!
Can you please confirm that XI does NOT need to modify anything in
/etc/openldap or if it does, why?
cdienger wrote:/etc/xinetd.d/nrpe & /etc/sysconfig/nagios these are not on a system by default and the group does not need write permissions. You can remove the write ability for the nagios group.
Done. As noted above, if I see them again after I run a manual upgrade again I'll report the details.
cdienger wrote:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh & scripts in /usr/local/nagiosxi/scripts/ - permissions by default look like "-rwxr-xr-x 1 root nagios". You can remove teh write ability for the nagios group.
Done.
A suggestion: for enhanced security, add to the
/usr/local/nagiosxi/scripts/reset_config_perms.sh script the fixing of the sensitive items in
/etc/sudoers with something like this:
Code: Select all
for item in $( grep /usr/local/nagios /etc/sudoers | cut -d: -f2 | tr ' ' '\n' | sort | uniq | grep /usr/local/nagios ) ; do
chown root:nagios $item
chmod 0550 $item
done
I admit it's a bit clunky but that's necessary because of the wildcards for args in some of the sudoers entries (which isn't thrilling either) plus the use of
/usr/bin/php with the
autodiscover_new.php script passed as an arg.
Anyway, the result of that code snippet is proper, safe user/group/mode on all the sudoers-referenced scripts:
Code: Select all
-r-xr-x--- 1 root nagios 169713 Sep 24 17:06 /usr/local/nagiosxi/html/includes/components/autodiscovery/scripts/autodiscover_new.php
-r-xr-x--- 1 root nagios 12022 Sep 24 17:06 /usr/local/nagiosxi/html/includes/components/profile/getprofile.sh
-r-xr-x--- 1 root nagios 7625 Sep 24 17:06 /usr/local/nagiosxi/scripts/backup_xi.sh
-r-xr-x--- 1 root nagios 1776 Sep 24 17:06 /usr/local/nagiosxi/scripts/change_timezone.sh
-r-xr-x--- 1 root nagios 2634 Sep 24 17:06 /usr/local/nagiosxi/scripts/manage_services.sh
-r-xr-x--- 1 root nagios 3815 Sep 24 17:06 /usr/local/nagiosxi/scripts/manage_ssl_config.sh
-r-xr-x--- 1 root nagios 1688 Sep 24 17:06 /usr/local/nagiosxi/scripts/repair_databases.sh
-r-xr-x--- 1 root nagios 3604 Sep 24 17:06 /usr/local/nagiosxi/scripts/reset_config_perms.sh
-r-xr-x--- 1 root nagios 2920 Sep 24 17:06 /usr/local/nagiosxi/scripts/upgrade_to_latest.sh
Thanks cdienger!
