Linux – How to use the `$HOME` environment variable in systemd service files

In some cases of exploits, the payload which causes the exploit to execute might have to be very small. In these cases, a common technique is to have a small bootstrap payload which can load a payload delivered differently (this larger payload need not trigger the exploit).

In case of sudo etc, the user has control of the environment. So the user can potentially deliver larger payload using the environment, and have the relevant payload small enough, which can then search/load the actual.

Some typical bootstrap payloads search for a particular environment variable (like an easter EGG HUNT) to load and so would be named EGGS.

See here for instance: http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf

In this case, looks like you have found yourself a script kiddie

Times change and so do best practices.

The current best way to do this is to run systemctl edit myservice, which will create an override file for you or let you edit an existing one.

In normal installations this will create a directory /etc/systemd/system/myservice.service.d, and inside that directory create a file whose name ends in .conf (typically, override.conf), and in this file you can add to or override any part of the unit shipped by the distribution.

For instance, in a file /etc/systemd/system/myservice.service.d/myenv.conf:

[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"

Also note that if the directory exists and is empty, your service will be disabled! If you don't intend to put something in the directory, ensure that it does not exist.

For reference, the old way was:

The recommended way to do this is to create a file /etc/sysconfig/myservice which contains your variables, and then load them with EnvironmentFile.

For complete details, see Fedora's documentation on how to write a systemd script.