opensnitch
opensnitch copied to clipboard
Update opensnitchd.service
Implements: #1018
Summary:
The systemd service unit can be enhanced to start BEFORE any network is configured, and thus allow interception and protection at an earlier stage...
Notable changes/additions:
-
Unit filename: :warning: The service filename needs tobe changed to
opensnitchd.service!!! This was needed for automatically using the unit name in the service definition using the%Nspecifier... See: Specifiers@mansystemd.unit#Specifiers- The filename, as packaged in latest v1.6.2 is lacking the
din it's name ! - Thus if you want to use this service file while at same time having the currently distributed unit file in your system you need to "mask" the old one to prevent it from being used and started:
sudo systemctl mask --now opensnitch.service
- The filename, as packaged in latest v1.6.2 is lacking the
-
Unit ordering: Made sure the daemon starts before any network related devices or services are created/started by using
network-pre.target, See:- Network pre-configuration@systemd.io
- how to start a systemd service before networking starts?@unix.stackexchange
-
Startup target / run-level: Changed the default install target to
basic.targetinstead ofmulti-user.target. This will allow it to run in any "run-level" in SysV terms. See: Units managed by the system service manager@mansystemd.special#basic.target -
Automatically disable using a kernel-command-line option: Just in case it is needed, i added the ability to disable the daemon using a kernel-command-line option using the
ConditionKernelCommandLinedirective. When theno-appfwoption is present in the kernel-command-line, the daemon will not startup. This option functions same as the well-knownquiteoption. (only applies when present as a separate word) -
Automatically create rules directory: Let systemd automatically create the "rules" directory with proper mode, when non-existent yet, upon starting the daemon service by using the
ConfigurationDirectoryandConfigurationDirectoryModedirectives. -
Automatically check for kernel support before starting: Automatically prevent startup when required kernel support is not present by using the
-check-requirementsflag in aExecConditiondirective. (This assumes the command returns a non-zero exit status when not satisfied.) -
Reload functionality: Added support for reloading the daemon using the
ExecReloaddirective. Signal-info was taken from the init.d script, but it just exits and then systemd restarts the service... So this functionality either needs to be implemented in the daemon's code or a different signal needs to be sent to it. But at least the functionality is now present in the unit file. -
Prevent from being killed by the OOM-Killer: Prevented the daemon to be killed by the Linux kernel's Out-Of-Memory (OOM) killer, using the
OOMScoreAdjust=-1000directive. See: OOMScoreAdjust@mansystemd.exec#OOMScoreAdjust(This will ensure that the protection keeps functioning even when other processes cause an OOM) -
Admin overrides using drop-ins: Added support for easily adjusting the directory used for rules and extra options by the local admin. The local admin can create "drop-in" config(s) under
/etc/systemd/system/opensnitchd.service.d/even when the service file is installed in other places by the package maintainer, See: 16.14. Extending the default unit configuration@redhat.com Example drop-in(s) contents that can-be-used:-
To change the rules directory to be used:
[Service] Environment='custom_cfg=%E/%N/rules-special'- The contents of
$custom_cfgis supplied as an argument to the-rules-pathoption of the daemon. - See: Specifiers@man
systemd.unit#Specifiers%Eexpands to/etc%Nexpands to the unit nameopensnitchd - Thus the total expansion of the above will become:
/etc/opensnitchd/rules-special
- The contents of
-
To enable debug output:
[Service] Environment='opts=-debug'- The contents of
$optsis supplied as extra argument(s) to the daemon.
- The contents of
-
Combination of both:
[Service] Environment='custom_cfg=%E/%N/rules-special' Environment='opts=-debug'
-
:warning:
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? :thinking:
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 :thinking:
(Ofcourse at same time fix the name of that file from opensnitch.service to opensnitchd.service, note the d at end of the name) :wink:
It will eliminate further discrepancies between the packaged version and the sources of the daemon...
@lainedfles in reply to https://github.com/evilsocket/opensnitch/issues/1018#issuecomment-1704532117
The version under your merge request did work without modification but here is my critique:
ExecStart=%Nwithout 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 byps. 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 :wink:
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=0700may 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... :woman_shrugging:
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 :wink:
WantedBy=basic.targetmay 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
$optsis 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 :+1:
The introduction of the custom_config variable may be unnecessary unless use of
EnvironmentFile=is planned. The structure of systemd makes it trivial to overrideConfigurationDirectory=which, since v240, will expose the$CONFIGURATION_DIRECTORYenvironment 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.targetmay 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
opensnitchdservice/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/etcis 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. :wink:
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 :+1: