PCR 7 covers the SecureBoot policy, in particular "dbx", i.e. the
denylist of bad actors. That list is pretty much as frequently updated
as firmware these days (as fwupd took over automatic updating). This
means literal PCR 7 policies are problematic: they likely break soon,
and are as brittle as any other literal PCR policies.
hence, pick safer defaults, i.e. exclude PCR 7 from the default mask.
This means the mask is now empty.
Generally, people should really switch to signed PCR policies covering
PCR 11, in combination with systemd-pcrlock for the other PCRs.
In v257 userdbctl gained support for filtering user records with fuzzy
matching and some other parameters. It was done on the client side only.
This PR adds server-side matching, by exendting the generic userdb
varlink api.
The api is generic any may have many other implementors, hence care is
taken to fallback to exclusively client side filtering in case the
service does not support the new parameters.
In fact I even opted to not actually implement server-side filtering in
any services but systemd-userdbd.service, because it's probably not too
much an optimization in relevant services (we might want to revisit this
later). By implementing it in userdbd the primary entrypoint for userdb
is however covered: the multiplexer interface which provides a single
interface for the multitude of backends. Or in other words: the
multiplexer itself supports server-side filtering even if its own
backends don't, and will hide this neatly away.
One nice side effect from not implementing server side filtering for all
our backends is that the fallback codepaths are comprehensively tested.
Note that this adds some unit tests but not new integration test for all
this, as the filtering tests for userdbctl already existed before, we
just move their implementation from the client to the server side.
"Recently" (as of 5.18) the Linux kernel gained the ability of locking
bridge ports to restrict network access to authenticated hosts only.
This is implemented by disabling automated learning and dropping
incoming traffic from unknown hosts. User space is then expected to add
fdb entries for authenticated hosts. Once a fdb entry exist, traffic for
that host will be forwarded as expected.
This was later extended with "Mac Authentication Bypass", where the
locking was extended to fdb entries. In this mode the kernel adds fdb
entries again automatically, but they are locked by default.
To properly configure this, add two network options and one netdev
option:
* `LinkLocalLearning=` to prevent the kernel from creating unlocked
entries based on link-local traffic, which would bypass any
authentication. Needed when enabling learning on a locked port.
* `Locked=` to allow setting a bridge port to locked.
* `MACAuthenticationBypass=` to allow enabling Mac Authentication
Bypass on a port. Requires learning to be enabled on the port as well
(and consequently `LinkLocalLearning` disabled on the bridge).
An authenticator (e.g. hostapd) is still needed to do the actual
authentication, the kernel only provides the access control.
Add a new flag, `--dns`, to systemd-networkd-wait-online to allow
waiting for DNS to be configured. The `--dns` flag respects the `--ipv4`
and `--ipv6` flags, as well as `--interface=` and `--any`.
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.
https://github.com/legionus/kbd/pull/127 adds a Georgian mapping
to kbd. console-setup already has one. Let's support it here, so
it's used for Georgian installs on distros that use this table.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Add a new method to io.systemd.Resolve.Monitor that allows subscribing
to changes in the systemd-resolved DNS configuration. The new method
emits the full DNS configuration (one entry for global configuration,
and one entry for each interface), any time the configuration is
updated.
This impelements server side filtering in userdbd's multiplexer logic.
Note thta this means that even if some backend doesn't support it
natively the multiplexer will deal with it and apply the filtering as
necessary.
This moves around the UserDBMatch handling, moves it out of userdbctl
and into generic userdb code, so that it can be passed to the server
side, to allow server side filtering.
This is preparation for one day allowing complex software to do such
filtering server side, and thus reducing the necessary traffic.
Right now no server side actually knows this, hence care is taken to
downgrade to the userdb varlink API as it was in v257 in case the new
options are not understood. This retains compatibility with any
implementation hence.
This is preparation for adding server side filtering to the userdb
logic: it adds some fields for this to the userdb varlink API. This only
adds the IDL for it, no client will use it for now, no server implement
it. That's added in later commits.
Take some of the same rule structure from 60-persistent-input.rules, and
apply it to hidraw devices in 60-persistent-hidraw.rules.
Since one of the motivations for this is being able to easily reference
FIDO tokens, add a special case when ID_FIDO_TOKEN==1, and add 'fido'
to the symlink.
The dbus property getter for DefaultRoute does not simply check
link->default_route. Instead, if l->default_route is not explicitly
configured, it checks dns_scope_is_default_route(l->unicast_scope).
Add a link_get_default_route() helper with this logic so that it can be
used for consistency.
We check this by opening a UDP socket and attempting to connect. We do
not send any traffic on it, but this will tell us if there are routes to
the DNS server.
This will be used in a later commit.
No functional change. Make it more clear that these varlink connections
are subscribed to query results. This prepares for adding SubscribeDNS
to the varlink API.
The varlink method io.systemd.Machine.Register() is in v256, hence type
of "leader" cannot be changed.
Let's revert the change by 755cb018c9, and
introduce another field "leaderProcessId", which takes detailed information
of the process.
Fixes a regression caused by 755cb018c9.
Fixes#36155.
Lennart Poettering
AndreFerreiraMsc
Yu Watanabe
Luca Boccassi
Luca Boccassi
Daan De Meyer
Nick Rosbrook
Jonas Gorski
Adam Williamson
Mike Yuan
ver4a
16mc1r