Let's log every time we use uninitialized PCRs when unsealing a secret
via TPM2. This indicates a firmware issue usually, and is something we
shouldn't just show when enrolling but also show every time we unseal,
so that the fact that the selected PCR policy is pretty much pointless
is repeatedly shown.
Previously, we hardcoded use of ECC as primary keys, since they are much
faster (i.e. saving multiple seconds) to do TPM2 operations with. Alas,
not all TPM2 chips appear to support ECC. Bummer.
Let's hence add a fallback logic: if we can't create an ECC primary key,
use an RSA key, and store that fact away.
AFIU the security guarantees should be roughly the same, it's just that
RSA primary keys is so much slower to work with than ECC.
The primary key algorithm is used is stored in the JSON header of LUKS
disks, in a new field. If the field is absent we assume to use ECC, to
provide full compatibility with old systemd versions.
The primary key algorithm is stored in a new field in the credentials
file format (in fact, a previously unused zero space is used), too.
Hopefully, this should ensure that TPM2 support will "just work" on more
systems.
Fixes: #20361
cryptenroll allows to specify a custom TPM driver separated from
parameters with colon e.g. `systemd-cryptenroll --tpm2-device=swtpm:`
tells to load swtpm tss driver and use it as a device.
Unfortunately it does not work, swtpm driver init() fails with
```
debug:tcti:src/tss2-tcti/tcti-swtpm.c:570:Tss2_Tcti_Swtpm_Init() Dup'd conf string to: 0x562f91cbc000
debug:tcti:src/util/key-value-parse.c:85:parse_key_value_string() parsing key/value: swtpm:
WARNING:tcti:src/util/key-value-parse.c:50:parse_key_value() key / value string is invalid
Failed to initialize TCTI context: tcti:A parameter has a bad value
```
It turns out that cryptenroll suppose to use the driver name internally
and strip it before passing the rest of parameters to init() function.
Without doing it swtpm receives incorrect key-value property and gets
confused.
Fix it by passing the correct parameter (without driver name) to the
init() function.
Fixes#20708
Our code logic doesn't support images with two verity partitions at the
moment, hence refuse this early (with ENOTUNIQ)
Also, go even further and refuse any combinations of verity enabled root
with verity-less /usr, simplify because that is unsafe and defeats the
point of verity. (i.e. we want to give the guarantee that for
auto-discovered verity magic we guarantee that the data afterwards
available in /usr is safe).
We already check whether we discovered a /usr verity partition without a
/usr partition when initially mangling the partitions, a bunch of lines
further up, no need to repeat this here.
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.
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}, ...]
In some cases it's useful to explicitly generate the JSON field names to
generate for table columns, instead of auto-mangling them from table
header names that are intended for human consumption.
This adds the infra and a test for it.
It's intended to be used by #20544, for the first column, which in text
mode should have an empty header field, but have an explicit name in
json output mode.
Kernel manages each genl family by its name, e.g. "nlctrl" or WG_GENL_NAME,
and its ID (used for nlmsg_type) is determined dynamically when the
corresponding module is loaded.
This commit makes sd-netlink follow the same way; now, sd_genl_family_t
is dropped, and sd_genl_message_new() takes a genl family name. Each
genl family is resolved when it is used first time, and its information
is stored in GenericNetlinkFamily.
Compound statements is this stuff: ({ … })
Compound literals is this stuff: (type) { … }
We use compound statements a lot in macro definitions: they have one
drawback though: they define a code block of their own, hence if macro
invocations are nested within them that use compound literals their
lifetime is limited to the code block, which might be unexpected.
Thankfully, we can rework things from compound statements to compund
literals in the case of json.h: they don't open a new codeblack, and
hence do not suffer by the problem explained above.
The interesting thing about compound statements is that they also work
for simple types, not just for structs/unions/arrays. We can use this
here for a typechecked implicit conversion: we want to superficially
typecheck arguments to the json_build() varargs function, and we do that
by assigning the specified arguments to our compound literals, which
does the minimal amount of typechecks and ensures that types are
propagated on correctly.
We need one special tweak for this: sd_id128_t is not a simple type but
a union. Using compound literals for initialzing that would mean
specifiying the components of the union, not a complete sd_id128_t. Our
hack around that: instead of passing the object directly via the stack
we now take a pointer (and thus a simple type) instead.
Nice side-effect of all this: compound literals is C99, while compound
statements are a GCC extension, hence we move closer to standard C.
Fixes: #20501
Replaces: #20512
Previously we only allows http/https urls, let's open this up a bit.
Why? Because it makes testing *so* *much* *easier* as we don't need to
run a HTTP server all the time.
CURL mostly abstracts the differences of http/https away from us, hence
we can get away with very little extra work.
Add support for systemd-pkcs11 based LUKS2 device activation
via libcryptsetup plugin. This make the feature (pkcs11 sealed
LUKS2 keyslot passphrase) usable from both systemd utilities
and cryptsetup cli.
The feature is configured via -Dlibcryptsetup-plugins combo
with default value set to 'auto'. It get's enabled automatically
when cryptsetup 2.4.0 or later is installed in build system.
Future systemd-pkcs11 plugin requires unlock via single
call with supplied pin. To reduce needless code duplication
in plugin itself split original pkcs_11_token_login call in
two calls:
new pkcs11_token_login_by_pin and the former where loop
for retrying via PIN query callback remains.
Follow-up for 406041b7de.
Also, this makes
- the settings accept an empty string,
- if the specified value is too large, also use the advertised maximum
value.
- mention the range of the value in the man page.
"max" indicates the hardware advertised maximum queue buffer size
should be used.
The max sizes can be checked by running `ethtool -g <dev>` (Preset maximums).
Since the buffer sizes can't be set to 0 by users, internally we use 0 to
indicate that the hardware advertised maximum should be used.