an idea for a subsystem for hardware monitoring

[BlackZork]

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

1. Create separate service "hwchecks" that will be run as root and will be able to execute plugin checks and return values to icinga2 daemon. For security reasons this service should not do anything else.
2. Add "use_root" to service definition. When use_root=true then service checks will be performed by "hwchecks".

[dnsmichi]

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

[Elias481]

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..

• At least on a per host base (if not per service) which mechanism is to be used. (Maybe someone does not want something else then sudo or let's say policykit to be used.)
• On a per service base which users/credentials/security-contexts etc, are desired.
• And whether at all to use sudo. It could be very handy to not need to have a command twice (once for sudo once for systems where it can or must be run without).

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:

• the logging for sudo can most probably be deactivated on most or all systems (it's just a matter of pam and sudo config) if that's ok for security
• 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 so the aspect "source code must be read before the command or script can be put to sudo config" in this context is not really vaid.. At least as long as the check command itself needs to be known for copying the command definition it's already known, for all other cases I would expect that the docs for such plugin specify which sudo permissions are needed to use it (and otherwise checking the icinga2 command definition for which command is called is affordable or could not be avoided)

[dgoetz]

@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.

[BlackZork]

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.

[Elias481]

@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.