Last week we looked at a traditional “inittab,” using AIX’s inittab as an example. This week, we’ll look at some of the “inittab” replacements that have popped up on various flavors of Linux.
As we mentioned last week, “Upstart” replaced “inittab” in Red Hat Enterprise Linux version 6, and “SystemD” unit files replaced it in RHEL7.
For Upstart, instead of a single “inittab” file, there is a directory called “/etc/init” that contains individual files that each control a single program to run. There is no specified order by name of file, and the configuration files don’t contain any ordering themselves, other than to say “start me after this other process.” With inittab, the order is controlled by where it falls within the file, so you get less fine grained control with this method, but you can be sure that a process that depends on another process already being up will wait, at least.
An interesting note about Upstart is that it doesn’t just check “/etc/init.” It can also live in “~/.init/” which would start jobs for a user rather than for the system, and these jobs wouldn’t run as children of PID 1. This gives some flexibility in dropping persistence in less explored locations on the file system, which means more places to audit for these kinds of persistence scripts.
An Upstart init file contains directives that respond to “emitted events.” The basic events are “starting, started, stopping, and stopped.” You can use a custom event that can be called by the emitter manually.
The program for sending “emitter events” to the Upstart “inittab” scripts is “initctl,” rather than “telinit.” Instead of a “telinit q” you would use “initctl <emitter event> <file name>” to stop, start, and so on.
For SystemD, there is no inittab, either. Everything is a Unit file, and lives in the same directory structure for both “init” type processes and “rc” type processes. For that reason, we won’t go into SystemD too much, today, but we will say this much that relates:
In the [Service] section of the Unit file, include the ExecStart directive to call the process you want to be started, the Restart directive to inform whether it should be “always” or “on-failure,” as well as a RestartSec directive to tell it to throttle the restart attempts so that it doesn’t restart as fast as possible.
SystemD also includes a different command from “telinit” for controlling the Unit files. The command “systemctl” will allow for starting, stopping, and status of the services controlled by Unit files.
Digging through all of the Unit files for the Exec lines and whether and how they are restarted is the key to looking for potentially persistent shells dropped in this manner. Remember, though, that just because a process isn’t set to “Restart” by directive doesn’t mean this isn’t calling a script that automatically loops on itself similarly to how we will cover other job types, later.