This is supeer useful to allow the normal sd-image code to be used by
someone who wants to setup multiple partitions with a sd-image.
Currently I'm manually copying the sd-image file and modifying it
instead.
This ensures that newly created secrets will have the permissions
`0640`. With this change it's ensured that no sensitive information will
be word-readable at any time.
Related to #121293.
Strictly speaking this is a breaking change since each new directory
(including data-files) aren't world-readable anymore, but actually these
shouldn't be, unless there's a good reason for it.
This is what is still exposed, and it allows me to control my lamps from
within home-assistant.
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3
✗ DeviceAllow= Service has a device ACL with some special devices 0.1
✗ IPAddressDeny= Service does not define an IP address allow list 0.2
✗ PrivateDevices= Service potentially has access to hardware devices 0.2
✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1
✗ SupplementaryGroups= Service runs with supplementary groups 0.1
✗ MemoryDenyWriteExecute= Service may create writable executable memory mappings 0.1
→ Overall exposure level for zigbee2mqtt.service: 1.3 OK 🙂
Until now, the `touch + chmod 600 + write` approach made it possible for
an unprivileged local user read the private key file, by opening
the file after the touch, before the read permissions are restricted.
This was only the case if `generatePrivateKeyFile = true` and the parent
directory of `privateKeyFile` already existed and was readable.
This commit fixes it by using `umask`, which ensures kernel-side that
the `touch` creates the file with the correct permissions atomically.
This commit also:
* Removes `mkdir --mode 0644 -p "${dirOf values.privateKeyFile}"`
because setting permissions `drw-r--r--` ("nobody can enter that dir")
is awkward. `drwx------` would perhaps make sense, like for `.ssh`.
However, setting the permissions on the private key file is enough,
and likely better, because `privateKeyFile` is about that file
specifically and no docs suggest that there's something special
about its parent dir.
* Removes the `chmod 0400 "${values.privateKeyFile}"`
because there isn't really a point in removing write access from
the owner of the private key.
- Set an explicit umask that allows u+rwx and g+r.
- Adds `ProtectControlGroups` and `ProtectKernelLogs`, there should be
no need to access either.
- Adds `ProtectClock` to prevent write-access to the system clock.
- `ProtectProc` hides processes from other users within the /proc
filesystem and `ProcSubSet` hides all files/directories unrelated to
the process management of the units process.
- Sets `RemoveIPC`, as there is no SysV or POSIX IPC within nginx that I
know of.
- Restricts the creation of arbitrary namespaces
- Adds a reasonable `SystemCallFilter` preventing calls to @privileged,
@obsolete and others.
And finally applies some sorting based on the order these options appear
in systemd.exec(5).
On reboots and shutdowns promtail blocks for at least 90 seconds,
because it would still try to deliver log messages for loki, which isn't
possible when the network has already gone down.
Upstreams example unit also uses a ten seconds timeout, something which
has worked pretty well for me as well.
systemd-nspawn can react to SIGTERM and send a shutdown signal to the container
init process. use that instead of going through dbus and machined to request
nspawn sending the signal, since during host shutdown machined or dbus may have
gone away by the point a container unit is stopped.
to solve the issue that a container that is still starting cannot be stopped
cleanly we must also handle this signal in containerInit/stage-2.
The upstream recommended minimum length for db_key_base is 30 bytes,
which our option descriptions repeated. Recently, however, upstream
has, in many places, moved to using aes-256-gcm, which requires a key
of exactly 32 bytes. To allow for shorter keys, the upstream code pads
the key in some places. However, in many others, it just truncates the
key if it's too long, leaving it too short if it was to begin
with. This adds a patch that fixes this and updates the descriptions
to recommend a key of at least 32 characters.
See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53602
This version contains a vulnerability[1], and isn't maintained. The
original reason to have two jellyfin versions was to allow end-users to
backup the database before the layout was upgraded, but these backups
should be done periodically.
[1]: <https://nvd.nist.gov/vuln/detail/CVE-2021-21402>
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
An empty list results in no CapabilityBoundingSet at all, an empty
string however will set `CapabilityBoundingSet=`, which represents a
closed set.
Related: #120617
The last bits to prevent babeld from running unprivileged was its
kernel_setup_interface routine, that wants to set per interface
rp_filter. This behaviour has been disabled in a patch that has been
submitted upstream at https://github.com/jech/babeld/pull/68 and reuses
the skip-kernel-setup config option.
→ Overall exposure level for babeld.service: 1.7 OK 🙂
some ban actions need additional packages (eg ipset). since actions can be
provided by the user we need something general that's easy to configure.
we could also enable ipset regardless of the actual configuration of the system
if the iptables firewall is in use (like sshguard does), but that seems very
clumsy and wouldn't easily solve the binary-not-found problems other actions may
also have.
it's not possible to set a different default maxretry value in the DEFAULT jail
because the module already does so. expose the maxretry option to the
configuration to remedy this. (we can't really remove it entirely because
fail2ban defaults to 5)
