Last week we looked at the User_Alias label. This week, we’re going to look at the Host_Alias label. Within a policy line, the “Host_Alias” is the next section of that policy. This dictates on which systems/servers this policy will be allowed to run.
When the policy is unique to each server, is not maintained as a centralized monolithic structure that gets shared out to all end points, or isn’t stored in a database such as LDAP, the usual default is the “ALL” entry. This simplifies figuring out which items to put here for a given server. It may seem like that answer is simple, but in reality, it’s not, due to the way sudo checks the host when called to execute a policy request.
What do I mean by that? The below snippet from the sudoers man page addresses this better than my own words ever could.
A Host_List is made up of one or more host names, IP addresses, network numbers, netgroups (prefixed with ‘+’) and other aliases.
If you do not specify a netmask along with the network number, sudo will query each of the local host's network interfaces and, if the network number corresponds to one of the hosts's network interfaces, the corresponding netmask will be used. The netmask may be specified either in standard IP address notation (e.g. 255.255.255.0 or ffff:ffff:ffff:ffff::), or CIDR notation (number of bits, e.g. 24 or 64). A host name may include shell-style wildcards (see the Wildcards section below), but unless the host name command on your machine returns the fully qualified host name, you'll need to use the fqdn option for wildcards to be useful. Note that sudo only inspects actual network interfaces; this means that IP address 127.0.0.1 (localhost) will never match. Also, the host name “localhost” will only match if that is the actual host name, which is usually only the case for non-networked systems.
As you can see, there is some reliance upon what the “host name” command returns, whether an IP is ever checked based on the actual network interfaces configured, and so on. The loopback interface is never checked. It is recommended to create a test policy with different Host_Alias entries that LOOK like they should work before making any assumptions about how your policy will actually behave once installed. If you frequently change the IP address(es) of your systems, a host name is preferred. If you change the name frequently, such as during a migration or similar, setting policy by IP might be better for your environment. Or maybe the name is better, and you include the name change inside your distributed monolithic policy file, or LDAP entry, or what have you. In the end, you need to figure out what will work best for your environment and be consistent with how you handle things. It doesn’t hurt to use both host name and IP in a policy, so you can set your alias label for either, or both.
Also, you can do negation with this just as you can with User_Alias entries. You could say “ALL, !www.example.com” to make this apply to any system that isn’t “www.example.com” (for example.)
The Host_Alias label is less important to change from the almighty “ALL” if you aren’t doing some kind of distributed shared policy, but if you get to more than a few end point servers that are not identical use case machines, you will eventually want to consider such a move. This is why it is important to learn how the Host_Alias actually behaves for policy on each machine, and test your policy to be sure it does what you expect.
Next week we’ll cover Runas_Alias, as it is the next section of a policy line.
Thanks for reading!