Previously, we'd clean up discovered /usr/ partition data only if we did
not find a root partition. Given that we allow combinations of root and
/usr partitions clean things up in both cases however.
Our code doesn't support setting up verity with an external verity data
file unless we operate in non-partitioned mode. Let's refuse this
clearly and early if attempted anyway.
For the GPT partitioned logic we also consult the fstype to determine whether
a partition is read-only (i.e. squashfs is already read-only). For the
non-partitioned mode we didn't do that so far. Fix that.
Let's also pick more precise names for these helpers that are used for
the tabular output: one checks whether a partition is candidate for
verity at all, and the other checks if it is ready to be used for it.
Let's make this clearer in the name.
Let's make the booleans indicating verity state a bit more descriptive.
Let's rename:
can_verity → has_verity: because that's really what this about
whether verity data is included in the image. Whether we actually
can use it is a different story.
verity → verity_ready: this one should tell us if we have everything
need to actually set it up, hence explicitly say "ready to use" in
the name.
No change in behaviour. Just a bit of renaming.
The Bootloader Specification says "devicetree refers to the binary
device tree to use when executing the kernel..", but systemd-boot
didn't actually do anything when encountering this stanza until now.
Add support for loading, applying fixups if relevant, and installing the
new device tree before executing the kernel.
Jamie Bainbridge found an issue where glib's g_get_user_database_entry()
may crash after doing:
```
error = getpwnam_r (logname, &pwd, buffer, bufsize, &pw);
// ...
pw->pw_name[0] = g_ascii_toupper (pw->pw_name[0]);
```
in order to uppercase the first letter of the user's real name. This is
a glib bug, because there is a different codepath that gets the pwd from
vanilla getpwnam instead of getpwnam_r as shown here. When the pwd
struct is returned by getpwnam, its fields point to static data owned by
glibc/NSS, and so it must not be modified by the caller. After much
debugging, Jamie Bainbridge has fixed this in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2244
by making a copy of the data before modifying it, and that resolves all
problems for glib. Yay!
However, glib is crashing even when getpwnam_r is used instead of
getpwnam! According to getpwnam_r(3), the strings in the pwd struct are
supposed to be pointers into the buffer passed by the caller, so glib
should be able to safely edit it directly in this case, so long as it
doesn't try to increase the size of any of the strings.
Problem is various functions throughout nss-systemd.c return synthesized
records declared at the top of the file. These records are returned
directly and so contain pointers to static strings owned by
libsystemd-nss. systemd must instead copy all the strings into the
provided buffer.
This crash is reproducible if nss-systemd is listed first on the passwd
line in /etc/nsswitch.conf, and the application looks up one of the
synthesized user accounts "root" or "nobody", and finally the
application attempts to edit one of the strings in the returned struct.
All our synthesized records for the other struct types have the same
problem, so this commit fixes them all at once.
Fixes#20679
cryptsetup_token_dump() gets called when the user calls
"cryptsetup luksDump" for a volume and it prints the token-specific
data.
The tpm2 cryptsetup_token_dump() function misspells tpm2 as tmp2 on two
lines of its output.
Fix that.
getpwnam_r() guarantees that the strings in the struct passwd that it
returns are pointers into the buffer allocated by the application and
passed to getpwnam_r(). This means applications may choose to modify the
strings in place, as long as the length of the strings is not increased.
So it's wrong for us to return a static string here, we really do have
to copy it into the application-provided buffer like we do for all the
other strings.
This is only a theoretical problem since it would be very weird for an
application to modify the pw_passwd field, but I spotted this when
investigating a similar crash caused by glib editing a different field.
See also:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2244
Idea is that all public APIs should take reference on objects that get
exposed to user-provided callbacks. We take the reference as a
protection from callbacks dropping it. We used to do this also here in
sd_event_loop(). However, in cleanup portion of f814c871e6 this was
accidentally dropped.
The `dracut_install` is a misnomer, since the systemd integration test
suite is based on the original dracut's test suite, and not all the
references to dracut has been edited out. Let's fix that.
FIDO2 device access is serialised by libfido2 using flock().
Therefore, make sure to close a FIDO2 device once we are done
with it, or we risk opening it again at a later point and
deadlocking. Fixes#20664.
The new option --json= works with the 'security' verb and takes in one of three format flags.
These are off which is the default, pretty and short which use JSON format flags for output.
When set to true, it generates a JSON formatted output of the security analysis table. The
format is a JSON array with objects containing the following fields: set which indicates if
the id has been set or not, name which is what is used to refer to the id, json_field
which is the equivalent JSON formatted id name only used for JSON outputs, description which
is an outline of the id state, and exposure which is an unsigned integer in the range 0.0..10.0,
where a higher value corresponds to a higher security threat. The JSON version of the table is
printed on the standard output file.
Example Run:
The unit file testfile.service was created to test the --json= option
maanya-goenka@debian:~/systemd (json-security)$ cat <<EOF >testfile.service
> [Service]
> ExecStart = echo hello
> PrivateNetwork = yes
> PrivateMounts = yes
> PrivateDevices = yes
> EOF
Both the JSON output and the security analysis table below have been truncated to increase readability.
1. Testing for when --json=off
maanya-goenka@debian:~/systemd (json-security)$ sudo build/systemd-analyze security --json=off --root= --offline=true
testfile.service --no-pager
/usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
/usr/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
/usr/lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your
unit file, and consider removing the setting altogether.
/home/maanya-goenka/systemd/foo.service:2: Unknown key name 'foo' in section 'Unit', ignoring.
NAME DESCRIPTION EXPOSURE
✓ PrivateNetwork= Service has no access to the host's network
✗ User=/DynamicUser= Service runs as root user 0.4
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities 0.3
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has administrator privileges 0.3
→ Overall exposure level for testfile.service: 8.3 EXPOSED 🙁
2. Testing for when --json=pretty
maanya-goenka@debian:~/systemd (json-security)$ sudo build/systemd-analyze security --json=pretty --root= --offline=true
testfile.service
/usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
/usr/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
/usr/lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your
unit file, and consider removing the setting altogether.
/home/maanya-goenka/systemd/foo.service:2: Unknown key name 'foo' in section 'Unit', ignoring.
[
{
"set" : true,
"name" : "PrivateNetwork=",
"json-field" : "PrivateNetwork",
"description" : "Service has no access to the host's network",
"exposure" : null
},
{
"set" : false,
"name" : "User=/DynamicUser=",
"json-field" : "UserOrDynamicUser",
"decsription" : "Service runs as root user",
"exposure" : "0.4"
},
{
"set" : false,
"name" : "CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP)",
"json_field" : "CapabilityBoundingSet_CAP_SET_UID_GID_PCAP",
"description" : "Service may change UID/GID identities/capabilities",
"exposure" : "0.3"
},
{
"set" : false,
"name" : "CapabilityBoundingSet=~CAP_NET_ADMIN",
"json_field" : "CapabilityBoundingSet_CAP_NET_ADMIN",
"description" : "Service has administrator privileges",
"exposure" : "0.3"
},
...
]
3. Testing for when --json=short
maanya-goenka@debian:~/systemd (json-security)$ sudo build/systemd-analyze security --json=short --root= --offline=true
testfile.service
/usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
/usr/lib/systemd/system/dbus.socket:5: ListenStream= references a path below legacy directory /var/run/, updating
/var/run/dbus/system_bus_socket → /run/dbus/system_bus_socket; please update the unit file accordingly.
/usr/lib/systemd/system/gdm.service:30: Standard output type syslog is obsolete, automatically updating to journal. Please update your
unit file, and consider removing the setting altogether.
/home/maanya-goenka/systemd/foo.service:2: Unknown key name 'foo' in section 'Unit', ignoring.
[{"set":true,"name":"PrivateNetwork=", "json_field":"PrivateNetwork", "description":"Service has no access to the host's network","exposure":null}, ...]
For most fields, the text shown by `.id` is the value that should be set
in the unit file; however, for RestrictNamespaces, it is not. Changing
this to show the actual text makes it more clear to a user what the
actual change that needs to be made to the unit file is.
When attaching a portable service with extensions, immediately validate
that the os-release and extension-release metadata values match, rather
than letting it fail when the units are started
Lennart Poettering
Emil Renner Berthing
Chris Packham
Daan De Meyer
Yu Watanabe
Michael Catanzaro
Anssi Hannula
Zbigniew Jędrzejewski-Szmek
Jan Kuparinen
Takuro Onoue
Andika Triwidada
Luca Boccassi
Michal Sekletar
xujing
Frantisek Sumsal
pedro martelletto
Maanya Goenka
Kyle Laker
Ross Jennings
lainahai
saikat0511