Open BlackZork opened 5 years ago
Thanks for the idea. The same idea applies for icmp checks, etc. and follows the idea of #7160. Yet I am not sure if and how this could work, cc @lippserd. Needs a concept/design and possible funding.
Cheers, Michael
Interesting idea. If an icinga2-sudo would be implemented it would be very fine if also SELinux transititons could be implemented with that. With only sudo and for programs that are not properly labeled (or for use cases where multiple different contexts could apply if icinga2_t executes them) this is really a hassle up to impossible without a hole (due to sudo only allowing a default SELinux context to be defined which can be freely overridden by caller as far as SELinux itself permits the transition).
Also for the icinga2 Part it would be fine to have a switch for "sudo". Anyway it should then be more configurable..
For implementation I think that would need to be implemented as an own implementation of sudo or polkit or the like with all the security checks done by them (and better with the possibility for security-logging for enviroments where that is desired or needed).
Besides that such an implementation could provide the missing features of sudo (SELinux and Capabilities related, and possibly with a more flexible/secure permissions parsing allowing regexes instead of only wildcard chars in the command line and such things) and could drop a dependency on an separate sudo mechanism, it could possibly provide a small efficiency benefit by dropping all the stuff sudo does which is not really necessary for a dedicated use case and a more easy possibility to avoid log entries.
Regarding the aspects described in the issue:
@Elias481: For SELinux we have to define every transition in the policy and I will only add those of plugins, (and perhaps if there is a reasonable exception). If a plugin than should execute a transition this has to be added to the nagios policy which defines it (except from the notification plugin domain). But if you want to add your own transition the Icinga 2 policy offers an interface for transitions and nagios one for plugins.
to be secure there must be a list of allowed actions anyway that is only changable by a administrative user on the system, so that aspect would remain unchanged
My idea for this service (icinga2-sudo) is to run anything that is configured in service checks by default. This is an action list, so why to repeat it elsewhere?
If I have [ PluginDir+ do_my_check.sh ]
with use_root=yes then it should not matter to me if my_check.sh is calling hddtemp, storcli or any other binary.
@BlackZork if You allow icinga2 program/user to run everything as root this is almost the same as running icinga2 as root which is not a good idea for any networked daemons (and for other programs neighter).
Of course it is enough to configure do_my_check.sh
in sudoers as it is with sudo, then admin is responsible to only allow sudo for scripts that are not changeable by icinga2 (or other "untrusted") user.
All in all I do not see any big advantage in implementing sudo in icinga (beside that the logging could be avoided more simple) but a shortcut to enable sudo on a per service basis would be fine anyway.
@dgoetz it was specifically a transition to unconfined for specific tool running sudo. It was a hassle and we have no really strong SElinux skills / ressources for that kind of investigation. The specific problem was that the tool itself was unlabeled. We decided for proper SElinu way then (labelled the tool to execute and allowed icinga type to transistion to unconfined when executing this program), I forgot. So forget about that.
Is your feature request related to a problem? Please describe.
Most of plugins that read hardware parameters (hddtemp, smartctl) needs read or write access to specific devices or even root privileges (in case of smartctl).
I need to use sudo for icinga to be able to use them. This floods journal log with tons of messages like:
May 09 00:00:26 black sudo[1153]: icinga : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/hddtemp -n /dev/sdb May 09 00:00:26 black sudo[1153]: pam_unix(sudo:session): session opened for user root by (uid=0) May 09 00:00:26 black sudo[1153]: pam_unix(sudo:session): session closed for user root
Additionally it is hard to setup such plugins - you need to read source code, figure out what binaries are called and add them to /etc/sudoers.d
Describe the solution you'd like