⚠️
The service file as distributed in the deb package still has WRONG name !!!
Someone needs to fix the packaging script !

@evilsocket seems #118 was not proper after all? 🤔

I think i found the spot where the packaged version in the deb differs from what is actually meant to be used:

• https://github.com/evilsocket/opensnitch/blob/master/utils/packaging/daemon/deb/debian/opensnitch.service

@gustavo-iniguez-goya could you please make that file a symbolic link to the one in the master tree at: https://github.com/evilsocket/opensnitch/blob/master/daemon/opensnitchd.service 🤔
(Ofcourse at same time fix the name of that file from opensnitch.service to opensnitchd.service, note the d at end of the name) 😉

It will eliminate further discrepancies between the packaged version and the sources of the daemon...

@lainedfles in reply to #1018 (comment)

The version under your merge request did work without modification but here is my critique:

ExecStart=%N without absolute path is bad practice from a security perspective although technically it should be safe under most modern distributions which have "merged" /bin via symbolic links and properly compiled systemd. It does also affect the process list as viewed by ps. My vote will always be to use absolute path if presented with a choice 👍

When not using absolute paths, systemd is using it's own default (build-in) path to find the executables see: systemd-path search-binaries-default.
Thus if using non-absolute paths in this context would make you worry about security, you should not trust systemd to start with 😉

The present state of Makefile relies upon the OS/user umask for directory permissions during creation or packaging of /etc/opensnitch/rules, for this reason, hard coding ConfigurationDirectoryMode=0700 may not be a good idea as it can produce a mismatch warning. Omission of this statement may be a better option unless creation is also dependent on systemd which likely isn't the reality for most distributions.

That makefile could/should be changed to use this access-mode anyway to make that directory more secure... 🤷‍♀️
man systemd.exec mentions "Defaults to 0755" which is an insecure value for this directory, that's why i override the default access-mode used.
What is more important to you, improved security settings or warnings due to insecure settings?
In the later case a manual chmod of that directory will both eliminate the warning and secure your settings more...
I stand by my choice of making the default access-mode of this directory 0700 😉

WantedBy=basic.target may become problematic for initrd boot because basic.target is reached before any filesystems are mounted. However, I think that the directives under [Unit] should catch this case under most circumstances so it may be a non-issue but worth mention.

The opensnitchd service/daemon is not started inside the initrd so that's not an issue.
Also the dependencies used under [Unit] make sure it is started way after /etc is mounted anyhow.

There is a benign warning if $opts is unset. I'd recommend setting an empty variable as a better practice. Like: Environment='opts='

Nice catch, i expected for it to become empty in the expansion so i didn't expect that 👍

The introduction of the custom_config variable may be unnecessary unless use of EnvironmentFile= is planned. The structure of systemd makes it trivial to override ConfigurationDirectory= which, since v240, will expose the $CONFIGURATION_DIRECTORY environment variable automatically that we can re-use.

It can be removed when the functionality you mention is implemented, but until then lets keep it in the unit.

I'm presently using a modified version incorporating these items. This version produces no systemd warnings under my up-to-date Archlinux system(s):

--- /etc/systemd/system/opensnitchd.service_TriMoon 2023年09月03日 19:54:32.833663095 -0600
+++ /etc/systemd/system/opensnitchd.service 2023年09月03日 20:18:11.745180152 -0600
@@ -16,13 +16,13 @@
 [Service]
 Type=exec
 ConfigurationDirectory=%N/rules
-ConfigurationDirectoryMode=0700
 
-Environment='custom_cfg=%E/%N/rules'
+# Example to enable daemon debug logging:
 # Environment='opts=-debug'
+Environment='opts='
 
-ExecCondition=%N -check-requirements
-ExecStart=%N -rules-path $custom_cfg $opts
+ExecCondition=/usr/bin/%N -check-requirements
+ExecStart=/usr/bin/%N -rules-path $CONFIGURATION_DIRECTORY $opts
 
 # Signal-info was taken from the init.d script, but it just exits and then systemd restarts the service...
 ExecReload=kill -HUP $MAINPID

WantedBy=basic.target may become problematic for initrd boot because basic.target is reached before any filesystems are mounted. However, I think that the directives under [Unit] should catch this case under most circumstances so it may be a non-issue but worth mention.

The opensnitchd service/daemon is not started inside the initrd so that's not an issue. Also the dependencies used under [Unit] make sure it is started way after /etc is mounted anyhow.

If things do go wrong or just to be extra specific we could add After=local-fs.target under [Unit], but i don't forsee any need at moment. 😉

Any progress here ?

@luzpaz ,If i would have made any more changes they would be shown in this thread as commits so no, the PR is still waiting for merging/acceptance...

Feel free to do a review if you want though 👍

Note, Debian uses fragments from this patch in 1030-systemd-service-earlier.patch. It would be nice to know if at least these parts will make it into master.

In NixOS we currently hand-roll our own minimal version of the systemd service here, without any of these patches: https://github.com/NixOS/nixpkgs/blob/ee930f9755f58096ac6e8ca94a1887e0534e2d81/nixos/modules/services/security/opensnitch.nix#L202-L245

I was intending to add the systemd hardening options to opensnitch, and i was considering upstreaming those - that would result in a merge conflict on this file, but is mostly an orthogonal change set in terms of logic.