picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Systemd/units/systemd-hostnamed.service.in

44 lines
1.2 KiB
SYSTEMD
Raw Permalink Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 05:23:58 +01:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Add SPDX license headers to unit files
2017-11-18 17:35:03 +01:00
#
hostnamed: introduce systemd-hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed
2011-04-16 02:02:54 +02:00
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
relicense to LGPLv2.1 (with exceptions) We finally got the OK from all contributors with non-trivial commits to relicense systemd from GPL2+ to LGPL2.1+. Some udev bits continue to be GPL2+ for now, but we are looking into relicensing them too, to allow free copy/paste of all code within systemd. The bits that used to be MIT continue to be MIT. The big benefit of the relicensing is that closed source code may now link against libsystemd-login.so and friends.
2012-04-12 00:20:58 +02:00
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
hostnamed: introduce systemd-hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed
2011-04-16 02:02:54 +02:00
# (at your option) any later version.
[Unit]
Description=Hostname Service
man,units: link to the new dbus-api man pages
2020-09-29 08:03:10 +02:00
Documentation=man:systemd-hostnamed.service(8)
Documentation=man:hostname(5)
Documentation=man:machine-info(5)
Documentation=man:org.freedesktop.resolve1(5)
hostnamed: introduce systemd-hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed
2011-04-16 02:02:54 +02:00
[Service]
BusName=org.freedesktop.hostname1
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 13:23:27 +02:00
CapabilityBoundingSet=CAP_SYS_ADMIN
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
ExecStart=@rootlibexecdir@/systemd-hostnamed
IPAddressDeny=any
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
units: make use of PrivateTmp=yes and PrivateDevices=yes for all our long-running daemons
2014-03-19 16:45:28 +01:00
PrivateDevices=yes
core: enable PrivateNetwork= for a number of our long running services where this is useful
2014-03-19 23:08:39 +01:00
PrivateNetwork=yes
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
PrivateTmp=yes
units: turn on ProtectProc= wherever suitable
2020-08-06 14:50:38 +02:00
ProtectProc=invisible
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 13:23:27 +02:00
ProtectControlGroups=yes
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
ProtectHome=yes
units: turn on ProtectProc= wherever suitable
2020-08-06 14:50:38 +02:00
ProtectKernelLogs=yes
units: turn on ProtectKernelModules= for most long-running services
2017-02-09 11:09:50 +01:00
ProtectKernelModules=yes
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
ProtectKernelTunables=yes
ProtectSystem=strict
hostnamed,shared/hostname-setup: expose the origin of the current hostname In hostnamed this is exposed as a dbus property, and in the logs in both places. This is of interest to network management software and such: if the fallback hostname is used, it's not as useful as the real configured thing. Right now various programs try to guess the source of hostname by looking at the string. E.g. "localhost" is assumed to be not the real hostname, but "fedora" is. Any such attempts are bound to fail, because we cannot distinguish "fedora" (a fallback value set by a distro), from "fedora" (received from reverse dns), from "fedora" read from /etc/hostname. /run/systemd/fallback-hostname is written with the fallback hostname when either pid1 or hostnamed sets the kernel hostname to the fallback value. Why remember the fallback value and not the transient hostname in /run/hostname instead? We have three hostname types: "static", "transient", fallback". – Distinguishing "static" is easy: the hostname that is set matches what is in /etc/hostname. – Distingiushing "transient" and "fallback" is not easy. And the "transient" hostname may be set outside of pid1+hostnamed. In particular, it may be set by container manager, some non-systemd tool in the initramfs, or even by a direct call. All those mechanisms count as "transient". Trying to get those cases to write /run/hostname is futile. It is much easier to isolate the "fallback" case which is mostly under our control. And since the file is only used as a flag to mark the hostname as fallback, it can be hidden inside of our /run/systemd directory. For https://bugzilla.redhat.com/show_bug.cgi?id=1892235.
2020-12-04 19:40:34 +01:00
ReadWritePaths=/etc /run/systemd
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 13:23:27 +02:00
RestrictAddressFamilies=AF_UNIX
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
RestrictNamespaces=yes
RestrictRealtime=yes
units: turn on RestrictSUIDSGID= in most of our long-running daemons
2019-03-20 19:52:20 +01:00
RestrictSUIDSGID=yes
units: set SystemCallArchitectures=native on all our long-running services
2017-02-08 22:32:37 +01:00
SystemCallArchitectures=native
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service sethostname
meson: allow WatchdogSec= in services to be configured As discussed on systemd-devel [1], in Fedora we get lots of abrt reports about the watchdog firing [2], but 100% of them seem to be caused by resource starvation in the machine, and never actual deadlocks in the services being monitored. Killing the services not only does not improve anything, but it makes the resource starvation worse, because the service needs cycles to restart, and coredump processing is also fairly expensive. This adds a configuration option to allow the value to be changed. If the setting is not set, there is no change. My plan is to set it to some ridiculusly high value, maybe 1h, to catch cases where a service is actually hanging. [1] https://lists.freedesktop.org/archives/systemd-devel/2019-October/043618.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1300212
2019-10-25 12:17:24 +02:00
@SERVICE_WATCHDOG@