The issue #12953 is caused by the following:
On switching root,
- deserialized_found == DEVICE_FOUND_UDEV | DEVICE_FOUND_MOUNT,
- deserialized_state == DEVICE_PLUGGED,
- enumerated_found == DEVICE_FOUND_MOUNT,
On switching root, most devices are not found by the enumeration process.
Hence, the device state is set to plugged by device_coldplug(), and then
changed to the dead state in device_catchup(). So the corresponding
mount point is unmounted. Later when the device is processed by udevd, it
will be changed to plugged state again.
The issue #23208 is caused by the fact that generated udev database in
initramfs and the main system are often different.
So, the two issues have the same root; we should not honor
DEVICE_FOUND_UDEV bit in the deserialized_found on switching root.
This partially reverts c6e892bc0e.
Fixes#12953 and #23208.
Replaces #23215.
Co-authored-by: Martin Wilck <mwilck@suse.com>
Previously, in sd_device_new_from_subsystem_sysname(), '/' in sysname
was replaced '!' for several limited subsystems. This was based on a wrong
assumption that no sysname in e.g. driver subsystem does not contain '!'.
And the assumption is actually wrong, and trigger issue #23327.
In device_set_sysname_and_sysnum() we unconditionally replace '!' in the
filename. Hence, the translation in sd_device_new_from_subsystem_sysname()
must be also done unconditionally.
Fixes#23327.
Without the size limits, oss-fuzz creates huge samples that time out. Usually
this is because some of our code has bad algorithmic complexity. For data like
configuration samples we don't need to care about this: non-rogue configs are
rarely more than a few items, and a bit of a slowdown with a few hundred items
is acceptable. This wouldn't be OK for processing of untrusted data though.
We need to set the limit in two ways: through .options and in the code. The
first because it nicely allows libFuzzer to avoid wasting time, and the second
because fuzzers like hongfuzz and afl don't support .options.
While at it, let's fix an off-by-one (65535 is the largest offset for a
power-of-two size, but we're checking the size here).
Co-authored-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
The methods published by the example have a reply in the signature, but
the code was not sending any, so the client gets stuck waiting for a
response that doesn't arrive. Echo back the input string.
Update the object path to follow what would be the canonical format.
Request a service name on the bus, so that the code can be dropped in a
service and it can be dbus-activatable. It also makes it easier to see
on busctl list.
test-execute checks that only /var/lib/private/waldo is writable, but there are
some filesystems that are always writable and excluded. Add /sys/devices/system/cpu
which is created by lxcfs.
Fixes https://github.com/systemd/systemd/issues/23263
With an intentional mistake:
../src/login/logind-dbus.c: In function ‘bus_manager_log_shutdown’:
../src/login/logind-dbus.c:1542:39: error: format ‘%s’ expects a matching ‘char *’ argument [-Werror=format=]
1542 | LOG_MESSAGE("%s %s", message),
| ^~~~~~~
Also break some long lines for more uniform formatting. No functional change.
I went over all log_struct, log_struct_errno, log_unit_struct,
log_unit_struct_errno calls, and they seem fine.
This is trivially exploitable (in the sense of causing a crash from SEGV) e.g.
by 'shutdown now "Message %s %s %n"'. The message is settable through polkit,
but is limited to auth_admin:
<action id="org.freedesktop.login1.set-wall-message">
<description gettext-domain="systemd">Set a wall message</description>
<message gettext-domain="systemd">Authentication is required to set a wall message</message>
<defaults>
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
</defaults>
</action>
Bug introduced in 9ef15026c0
('logind/systemctl: introduce SetWallMessage and --message', 2015-09-15).
UEFI provides a "monotonic boot counter" which is supposed to increase on
each reboot. We can include this in our random seed hash logic, which
makes things more robust in case our changes to the ESP end up not
actually being as persistent as we assume. As long as the monotonic boot
counter increases we should be good, as each boot we'll anyway end up
with a new seed that way.
This in fact should also pave the way that we can eventually enable the
random seed logic even on SecureBoot enabled systems. Why that? With
this change the input for the random seed hash is now:
1. the old seed file contents
2. (optionally) some bits from the UEFI RNG
3. (optionally) a per system random "token" stored in an UEFI variable,
initialized at OS install
4. the UEFI monotonic counter
5. a counter integer used by the random seed logic.
We can ignore #5 entirely for security considerations, it's always going
to be a constant series of values determined by the random seed logic.
The #1 file is under control of the attacker. (Since it resides in the
unprotected ESP)
The #2 data is possibly low quality. (it's hard enough to trust the
quality of the Linux RNG, let's not go as far as trusting the UEFI one)
The #3 data should not be under control of the attacker, and should only
exist if explicitly set. Unless you have privileged access to the system
you should not be able to read or set it. (well, within limits of flash
chip security and its connectivity to the firmware)
The #4 data is provided by the firmware, and should not be under control
of the attacker. If it works correctly then it might still be guessable
(i.e. a new system might have the counter close to zero).
Thus: 1+2+5 are guessable/under control of attacker, but 3+4 should not
be. Thus, if 3 is not known to attacker and not guessable, and 4
strictly monotonically increasing then it should be enough to guarantee
that every boot will get a different seed passed in, that should not be
known or guessable by the attacker.
That all said, this patch does not enable the random seed logic on
SecureBoot. That is left for a later patch.