Systemd Service Hardening

When was the last time you ran
systemd-analyze security

Homework
https://www.linuxjournal.com/content/systemd-service-strengthening
https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04
man systemd.unit
man systemd.directives

Tips and tricks:
Do not modify service files. Create a drop-in file with the
[section]
and whatever directives you want changed.

Homework
Run a google search for systemd drop-in

I find it more productive to have a boilerplate or skeleton file
for common type coding. Examples
$ ls -1 *skeleton*
bash_skeleton
install_skeleton
skeleton_changes
skeleton_sb_drop_in_changes
skeleton_service_changes

The skeleton files have has about 80% of the common code
for parsing command line, commands for arguments and usual
boilerplate code for the activity. You copy the skeleton file
to desired file name. change one or more variables, and then
start hacking away at the code to have it do whatever you like.

For example skeleton_sb_drop_in_changes.
I would
cp skeleton_sb_drop_in_changes mlocate_sb_drop_in_changes
edt mlocate_sb_drop_in_changes
and do a global change of drop_in to mlocate

code already exist to create/remove the drop-in file and
directory and all the directives with my desired settings.

Nothing left to do except delete/change desired directives for
the mlocate service.

Now I need a script to execute all the sandbox scripts.
cp skeleton_changes sb_drop_in_changes
and hack it to have

while read -r line ; do
$line "$_arg1"
done < <(ls -1 /local/bin/*_sb_drop_in_changes)

Then edit install_changes and add
/local/bin/sb_drop_in_changes

install_changes is the last command I run during a clean
install to get the last of the change not already made.

On Sun, 16 May 2021 07:24:00 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:

> Systemd Service Hardening
>
> When was the last time you ran
> systemd-analyze security

Never. :-) As per it's man page, it simply shows whether or not the service
uses systemd features to protect the application, not whether or not the
application uses other features to protect itself or would in any way be more
secure if it did use the features.

While it may be beneficial to go through each and every one of the systemd
security features to restrict what services can do, it also requires knowing
which services the administrator wants to have restricted to localhost, available
to guests running on localhost, available to other systems on the lan, or
accessible from the internet, and what impact each of the systemd security settings
will have on the use of those services.

As it is, it's a lot of easy to misunderstand noise. While the idea of ensuring
applications only have access to features they need and can only be accessed by
other things when needed is good, making use of the additional systemd security
features requires detailed knowledge.

For example, "systemd-analyze security mlocate-updatedb.service" shows
✓ PrivateNetwork= Service has no access to the host's network
but later shows ...
✗ IPAddressDeny= Service does not define an IP address whitelist 0.2

So it's marking the service as insecure because it doesn't filter by ip address,
even though it has no network access. That's useless noise in my opinion.

It really needs an easy to use configuration tool with presets for each service
based on the type of usage desired.

I view it as a work in progress that will eventually become useful.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.