Let's allow configuring which UKI profiles we generate signed PCR
measurements for since there are various types of profiles for
which we do not want to generate signed PCR measurements so that they
can not unlock the encrypted rootfs.
Fixes#36173.
Add a new flag to systemd-networkd-wait-online, --dns, to allow waiting
for DNS to be configured.
DNS is considered configured when at least one DNS server is accessible.
If a link has the property DefaultRoute=yes (either by explicit
configuration, or because there are no routing-only domains), or if the
search domain '.' is configured, wait for link-specific DNS to be
configured. Otherwise, global DNS servers may be considered.
Since linux commit a35ec8e38cdd1766f29924ca391a01de20163931 ("bridge:
Add MAC Authentication Bypass (MAB) support"), included since v6.2, it
is possible to enable MAC Authentication Bypass for bridge ports. In
this mode the locked port learns again, but the learned fdb entries are
locked, allowing user space to unlock hosts based seen MAC addresses.
This requires learning to be enabled on the port, and link-local
learning disabled for the bridge.
Add support to systemd-network for setting the new attribute for bridge
ports.
Since linux commit a21d9a670d81103db7f788de1a4a4a6e4b891a0b ("net:
bridge: Add support for bridge port in locked mode"), included since
v5.18, it is possible to set bridge ports to locked.
Locked ports do not learn automatically, and discard any traffic from
unknown source MACs. To allow traffic, the userspace authenticator is
expected to create fdb entries for authenticated hosts.
Add support to systemd-network for setting the new attribute for bridge
ports.
When using locked ports on a bridge link-local learning needs to be
disabled to prevent the kernel from learning and automatically unlocking
hosts based on link-local traffic.
So add support for enabling NO_LL_LEARN for bridges.
With the following, now preferred source address is set to the DHCP
address.
====
[Route]
Gatewa=_dhcp4
Table=100
====
Before:
====
$ ip route show table 100 default
default via 192.168.0.1 dev eth0 proto dhcp metric 1024
====
After:
====
$ ip route show table 100 default
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.100 metric 1024
====
To avoid the assignment, this also introduces PreferredSource=no.
This adds the same sections we already have in the homectl --help blurb
also to the man page.
While we are at it, let's also add a new section for Authentication
related switches.
There's finally quota on tmpfs, hence let's use it to make it harder for
users to DoS the system by consuming all disk space in /tmp/ and
/dev/shm/.
This enforces a default limit of 80% quota of the backing fs for these
two dirs for users, but this can be overriden in the user record, if
desired.
This also adds two other interesting features:
1. mount units gain GracefulOptions= which takes optional mount options
that are added only if supported by the kernel. (this is used to enable
usrquota on /tmp/, if available.)
2. The PAM logic in service management now supports reading passwords
from service credentials and via the askpw logic. This used for make
testing easy (so that we can run0 into a homed user which strictly
requires a password).
So far nspawn supported unpriv containers only if backed by a DDI. This
adds dir-based unpriv containers too.
To make this work this introduces a new UID concept to systemd: the
"foreign UID range". This is a high UID range of size 64K. The idea is
that disk images that are "foreign" to the local system can use that,
and when a container or similar is invoked from it, a transiently
allocated dynamic UID range is mapped from that foreign UID range via id
mapped mounts.
This means the fully dynamic, transient UID ranges never hit the disk,
which should vastly simplify management, and does not require that uid
"subranges" are persistently delegated to any users.
The mountfsd daemon gained a new method call for acquiring an idmapped
mount fd for an mount tree owned by the foreign UID range. Access is
permitted to unpriv clients – as long as the referenced inode is located
within a dir owned by client's own uid range.
Enforce the quota on these two tmpfs at the same place where we mount
the per-user $XDG_RUNTIME_DIR. Conceptually these are very similar
concepts, and it makes sure to enforce the limits at the same place with
the same lifecycle.
Also, when a filename is specified, also search udev rules file in
udev/rules.d directories.
This also refuses non-existing files, and file neither nor a regular
nor a directory, e.g. /dev/null.
The "vice versa" in the old text could be interpreted as either
(wrong) "stopping the former will start the latter", or
(right) "starting the latter will stop the former".
Rephrase to avoid that ambiguity.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
This adds -D/--extra-rules-dir=DIR switch for 'udevadm test' command.
When specified, udev rules files in the specified directory will be also
loaded. This may be useful for debugging udev rules by copying some udev
rules files to a temporary directory.
Uses the newly added policy-digest verb of systemd-measure, for the same
purpose: build a UKI and get digests for the .pcrsig section out, so
that they can be offline signed and reattached
When doing offline signing we need to know the exact payload
to sign, and the 'calculate' verb doesn't really show that, it
shows the PCR values. But what we sign is the hash of the policy.
So add a new verb that outputs the json payload that goes in the
.pcrsig section, without the .sig object, so that we can take them
and give the .pol object to an offline and asynchronous signing
service, such as SUSE's Open Build Service, and then add the .sig
object to the json and attach it to a UKI.
This new setting can be used to specify mount options that shall only be
added to the mount option string if the kernel supports them.
This shall be used for adding "usrquota" to tmp.mount without breaking compat,
but is generally be useful.
This adds a new --lightweight=yes/no switch which allows controlling
whether the invoked service will have the service manager around or not.
Moreover, this changes that if the target user is root it will now
support to the lightweight mode, i.e. run0 towards root will no longer
pull in the service manager (a real tty login via getty still will
though!).
My thinking here is that quickly raising privileges via run0 probably
shouldn't be considered a proper login but just something short lived,
temporary for a single command or similar.
This new session class is to "user" what "background" is to
"background-light": it doesn't cause the per-user service manager to
start.
This new session class is now the default if no session class was
provided at session registration time and the following conditions hold:
1. The session is not graphical
2. The user is not a regular user (but not root)
Or in other words root and system users won't get a service manager
started automatically if they go through a PAM session as part of things
like cron or ftp. They will however still get one if they log in
graphically.
This changes behaviour a bit, but hopefully in OK was.
This also makes "background-light" for system users incl. root.
This addresses one of the ideas discussed in #34988.
The arm confidential compute architecture (CCA) provides a platform design for
confidential VMs running in a new realm context.
This can be detected by the existence of a platform device exported for the
arm-cca-guest driver, which provides attestation services via the realm
services interface (RSI) to the Realm Management Monitor (RMM).
Like the other methods systemd uses to detect Confidential VM's, checking
the sysfs entry suggests that this is a confidential VM and should only be
used for informative purposes, or to trigger further attestation.
Like the s390 detection logic, the sysfs path being checked is not labeled
as ABI, and may change in the future. It was chosen because its
directly tied to the kernel's detection of the realm service interface rather
to the Trusted Security Module (TSM) which is what is being triggered by the
device entry. The TSM module has a provider string of 'arm-cca-guest' which
could also be used, but that (IMHO) doesn't currently provide any additional
benefit except that it can fail of the module isn't loaded.
More information can be found here:
https://developer.arm.com/documentation/den0125/0300
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Let's clarify more explicitly that privileged calls to
systemd-notify --pid= and sd_pid_notify() effectively override any
configured NotifyAccess=main|exec for a service.
When copying a directory from or to an image, let's always merge
with existing directories instead of failing with "File Exists".
Fixes https://github.com/systemd/mkosi/issues/3342.
This is establish the basic concepts for #35685, in the hope to get this
merged first.
This defines a special, fixed 64K UID range that is supposed to be used
by directory container images on disk, that is mapped to a dynamic UID
range at runtime (via idmapped mounts).
This enables a world where each container can run with a dynamic UID
range, but this in no way leaks onto the disk, thus making supposedly
dynamic, transient UID range assignments persistent.
This is infrastructure later used for the primary part of #35685: unpriv
container execution with directory images inside user's home dirs, that
are assigned to this special "foreign UID range".
This PR only defines the ranges, synthesizes NSS records for them via
userdb, and then exposes them in a new "systemd-dissect --shift" command
that can re-chown a container directory tree into this range (and in
fact any range).
This comes with docs. But no tests. There are tests in #35685 that cover
all this, but they are more comprehensive and also test nspawn's hook-up
with this, hence are excluded from this PR.