| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
Follow-up for 7a3a49386cc49d3971531ea24efb84232c05cc86.
|
|
Follow-up for 39ce86d19c7c3ac46b4afb546879ca8dcad1bdb2.
|
|
Follow-up for 195bb6f97ebc5cd5e9932c62aa80df5427c30d67.
|
|
This was added to deal with a bug in the rpm 4.20 rc in Rawhide
but since that's been fixed, let's drop the workaround.
|
|
|
|
Fixes: #33772
|
|
Fixes: #33936
|
|
|
|
The .cred suffix is stripped from a credential as it is imported from
the ESP, hence it should not be included in the credential name embedded
in the credential.
Fixes: #33497
|
|
|
|
later extend
This options is pretty simple, it allows specifying an UKI whose
sections to import first, and place at the beginning of the new UKI.
This is useful for generating multi-profile UKIs piecemeal: generate the
base UKI first, then append a profile, and another one and another one.
The sections imported this way are not included in any PCR signature,
the assumption is that that already happened before in the imported UKI.
|
|
This just allows including .profile sections, but doesn't try to be
smart about it. This alone won't help you much to create valid
multi-profile UKIs.
|
|
Let's make clearer what we are going to use /dev/kmsg for: read/write or just
writing. This hopefully should avoid confusion, such as the one #33975
is result of.
(Also while we are at it, add one extra debug message).
Fixes: #33975
|
|
|
|
Let's make sure we erase TPM2B_SENSITIVE_DATA structures reliably in all
code paths.
|
|
So far you had to pick:
1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
dynamic local policy stored in NV index)
It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).
This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.
This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.
This means:
1. we simply double the unlock key in length in case both policies shall
be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
both halves of the LUKS unlock key.
This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
|
|
|
|
as NULL
Fixes: #34163
|
|
Apparently _PATH_UTMPX is a glibc'ism. UTMPX_FILE is the same thing and
what everyone else uses. Since they are otherwise equivalent, let's just
switch.
|
|
utmpx doesn't know these defines, hence fix them.
|
|
|
|
We generally use utmpx instead of utmp (both are actually identical on
Linux, but utmpx is POSIX, while utmp is not). Let's fix one left-over
case.
UT_NAMESIZE does not exist in utmpx world, it has no direct counterpart,
hence let's just sizeof_field() to determine the size of the actual
field. (which comes to the same result of course: 32).
|
|
In https://github.com/systemd/systemd/pull/5283/commits/924453c22599cc246746a0233b2f52a27ade0819
ProtectHome was set to true for systemd-coredump in order to reduce risk, since an attacker could craft a malicious binary in order to compromise systemd-coredump.
At that point the object analysis was done in the main systemd-coredump process.
Because of this systemd-coredump is unable to product symbolicated call-stacks for binaries running under /home ("n/a" is shown instead of function names).
However, later in https://github.com/systemd/systemd/commit/61aea456c12c54f49c4a76259af130e576130ce9 systemd-coredump was changed to do the object analysis in a forked process,
covering those security concerns.
Let's set ProtectHome to read-only so that systemd-coredump produces symbolicated call-stacks for processes running under /home.
|
|
Currently translated at 100.0% (253 of 253 strings)
Co-authored-by: Léane GRASSER <leane.grasser@proton.me>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/fr/
Translation: systemd/main
|
|
This introduces the concept, and makes sure systemd-measure covers it.
See a later commit for details on the new section.
|
|
This is the most basic preparatory work for supporting multi-profile
UKIs.
(This temporarily drops an assert_cc() check which we'll address in the
next commit)
|
|
detached
Follow-ups for db8dc7c1dd7f4620e14fbc4c1560a68a1fc9b85b.
Fixes #34275.
|
|
|
|
Fixes #34270.
|
|
Fixes #34273.
|
|
specified
Also do not chown if a device node is bind-mounted.
Fixes #34243.
|
|
|
|
|
|
|
|
|
|
|
|
This also
- rename variable n -> address,
- use log_syntax_parse_error() where applicable,
- add one more assertion for lvalue in config_parse_address().
|
|
Then, use generic conf parsers defined in conf-parser.[ch].
|
|
- use log_syntax_parse_error(),
- return 1 on success,
- drop unnecessary or redundant assertions,
- add missing log_oom().
|
|
It is similar to config_parse_uint32_flag(), but drops the specified flag
when true.
|
|
|
|
|
|
section
This also
- renames n -> label,
- use log_syntax_parse_error().
No functional change, just refactoring.
|
|
It will be used later.
|
|
Mark those Apple Wireless keyboards as not having a NumLock key:
https://en.wikipedia.org/wiki/Apple_Wireless_Keyboard
You can see that they don't have a NumLock LED because they didn't even
have a NumLock in the first place:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fea6fe7d5ef1b5fa5f78048d4729f85181c04ca
|
|
|
|
These message may be unnecessarily shown multiple times when e.g.
networkd is restarted, system is wakeup from suspend, and so on.
Closes #34262.
|
