I don’t think you should be using sudo and maybe you shouldn’t be using Linux at all.
The money quote. Love this. Article was well written with clear and helpful examples. Thanks, Tony.
via Understanding and using sudo in Unix or Linux (with examples).
Nobody has told me much about Linux, but I have learned vast amounts from the community. There is a downside to that, however. In an interactive conversation, certain things may come up that generate further discussion by their nature, whereas simple consumption from the web (or any other medium) may leave a vague hunch without actually provoking the “deeper dive”, if you will.
Such is the case, for me, with sudo and setuid. I’ve always had the impression that setuid was a “bad thing to do”™, because (in an overly broad and general sense) if your setuid application was compromised by a security flaw, your system was effectively compromised. sudo was “a good thing”™, because you could perform administrative functions easily without having to log out, log in as root, take care of the task at hand, and then return to your normal user shell.
Fast forward to today. I’ve been doing some testing with check_mk, and ran into an issue where the default host check utilizes the Nagios check_icmp plugin. When check_mk attempts to run same, it fails with an error indicating that the executable must be run as root or have setuid root set. I presume the reason Nagios (or “nagios”, if you want to call the process by its username) is able to perform the checks is because the process is initiated as root and drops privileges, but maintains the permissions required to interface with the network stack. In this case, (I think… haven’t proved it yet) it’s irrelevant. What I really want to know is – which is the better option to use, given that I can change the command used for the default check to use sudo if needed.
Jump... to conclusions!
After reading Tony’s article and taking into consideration that the sudo application itself is a setuid binary, I’m going to make a quick jump to conclusions that probably doesn’t much matter in any case, since the executable will be effectively running as root. I’m going to go with an edit to /etc/sudoers that will permit just the webserver account to run the plugin as root. I have two reasons for this approach, one or both of which may be wrong.
First, I suspect there have been a lot more eyes on the code for the sudo binary than on the Nagios plugin binary, and if there’s going to be a flaw in one, it’s probably the latter (n.b. – I would not expect to see a flaw in the Nagios code, either… monitoring systems are, by their very purpose, allowed to converse with very critical infrastructure and best practices in development and security should be priorities).
Second, using sudo I can allow limited access to run the plugin as root, restricting that ability to just the webserver user account. With setuid, any user who has the ability to execute the program (given a mask of 755, effectively everyone) can A.) run the program, and B.) do so as root.
In a perfect world – or maybe just a parallel dimension to this one – I could (and perhaps should) set the user and group ownership of the file more specifically, chmod o-x the plugins, and then chmod u+s the particular check_icmp plugin I needed. This would likely be a more achievable solution in cases where it is difficult or impossible to control how the binary is called.
EDIT: So, there’s an interesting new problem with this approach. While the return code from the executed plugin is provided as the return code from sudo, the data returned by the plugin is sadly missing. This makes sense, and it should have occurred to me. There are a few ways I could get it back: Fun with pipes, PID’s, and file descriptors using GDB (example here); parsing and passing the results as a passive host check to the Nagios external command file (might make sense since check_mk submits results as passive checks anyway). Probably others. At this juncture, I will probably at least test with the setuid bit set, and perhaps just leave it that way.
