Version 1.9.6 of sudo was released recently. This is primarily a bug fix release with almost no user visible changes. One of the changes visible to developers is that support for fuzz testing was added. What is fuzz testing? According to the Wikipedia: “Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.”

My FOSDEM talk in the BSD devroom showcased what is new in sudo and syslog-ng and explained how to install or compile the software yourself on FreeBSD. I am a long-time FreeBSD user, started with version 1.0 in 1994. But soon after my talk I was asked what I know about the other BSDs. I knew that all BSDs have sudo in their ports system, but had no idea what shape those ports were in.

While FreeBSD does not install sudo as part of the base system, you can easily install it yourself. If you do not need anything more than basic functionality, you can install the binary package using the pkg command. Most users belong to this group. If you need advanced functionality, like Python support, you will have to compile sudo yourself from ports.

Are you surprised by the mention of basic and advanced functionality for sudo? If yes, read my article about what is new in sudo 1.9. Besides there are lots of lesser-known features in sudo 1.8 as well. You will learn that sudo is more than just a prefix for administrative commands.

While most of the changes in sudo version 1.9.4 are under the hood, there are some user-visible changes as well. Locating problems in the sudoers file became even easier as the column number is now also displayed when an error is found. There are also two logging related changes. Sudo_logsrvd, the service that collects session recordings centrally, can now also collect rejection log messages, not just information about successful sessions. It is now also possible to log events in JSON format.

Version 1.9.3 brought many improvements to how the sudoers file is handled. Zero-length files are not saved by sudoedit, in many cases error messages are more accurate, and sudo no longer refuses to run if there is a syntax error. Let’s take a more detailed look at these changes!

These new features were introduced in sudo version 1.9.3. There is a good chance that your operating system includes an older version of sudo. You can download ready-to-use binaries for many different operating systems directly from the sudo website or you can build sudo from source yourself.

Starting with sudo 1.9.3, you can change both the root and the working directories within sudo itself. Neither option is enabled by default–you need to explicitly enable them in the sudoers file. When enabled, you can fine-tune target directories or allow your users to specify the directory to use. The logs reflect when these settings have been used.

These new features were introduced in sudo version 1.9.3. There is a good chance that your operating system includes an older version of sudo. You can download ready-to-use binaries for many different operating systems directly from the sudo website or you can build sudo from source yourself.

The default sudoers file gives one group of users full control over your machine:

%wheel ALL=(ALL) ALL

Once it is not just you and your best friend administering a machine, you will start to give more fine-grained privileges to administrators. All fields in the above configuration line can be replaced by a list of values. A list of user names, a list of host names, a list of commands, and so on. Soon you will copy and paste these lists around in your sudoers file. It looks simple and manageable at first, but soon the sudoers file no longer fits on your screen. This is the time (well, actually a lot earlier) when you should turn to aliases.

Version 1.9 of sudo introduced the approval plugin API, making it possible to have extra restrictions before executing a command. These only run after the policy plugin has succeeded, so you can effectively add additional layers of policy without replacing the policy plugin and sudoers. Multiple approval plugins may be defined, and all must succeed in order for the command to be executed.

In this blog you will find a simple Python script utilizing the approval API. It implements a simple check: if the current time is within a certain range the command is allowed. This script is part of the sudo documentation under the name example_approval_plugin.py.

Version 1.9 of sudo introduced a new API to access audit information. This is not a user-visible feature. In other words, you cannot use it directly from the sudoers file. It is an API, meaning that you can access audit information from plugins, including ones written in Python. You can use it in many different ways, like sending events from sudo directly to Elasticsearch or LaaS when something interesting happens. You can also use it for debugging and print otherwise difficult to access information to the screen in whatever format you like. In this blog you will find a simple Python plugin which displays information on the terminal when a command is run. It is derived from a more complex example that is available as part of the sudo package called example_audit_plugin.py.

Using the sudo group plugin, you can connect sudo to external systems and approve commands based on non-UNIX groups. For example, Authentication Services by One Identity uses this solution. Starting with version sudo 1.9, you can also write group plugins in Python. You can use this to check databases or APIs if the admin trying to run a command is a member of a group. This way you can check, for example, if an admin is on duty.