IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
So far the --help text and the man page of journactl were mostly a large
pile of options shown next to each other. Let's add some basic
structure, and group switches by sections such as "Filtering Options",
"Output Options" and so on.
Do this the same way in the --help text and in the man page.
Since this moves everything around anyway, I also opted to rebreak all
paragraphs in the man page. This makes the patch larger than necessary,
but given that this whole patch doesn't really change contents besides
section titles I figured this would be OK.
Adding Microsoft keys by default is recommended because firmware drivers
might be signed by it.
This also changes the file ending from .esl to .auth as that is used by
sign-efi-sig-list manpage and other sources.
This command takes a mountpoint, unmounts it and makes sure the
underlying partition devices and block device are removed before
exiting.
To mirror the --mount operation, we also add a --rmdir option which
does the opposite of --mkdir, and a -U option which is a shortcut
for --umount --rmdir.
***DANGER*** NOTE ***DANGER***
This feature might result in your device becoming soft-brick as outlined
below, please use this feature carefully.
***DANGER*** NOTE ***DANGER***
If secure-boot-enrollment is set to no, then no action whatsoever is performed,
no matter the files on the ESP.
If secure boot keys are found under $ESP/loader/keys and secure-boot-enrollment
is set to either manual or force then sd-boot will generate enrollment entries
named after the directories they are in. The entries are shown at the very bottom
of the list and can be selected by the user from the menu. If the user selects it,
the user is shown a screen allowing for cancellation before a timeout. The enrollment
proceeds if the action is not cancelled after the timeout.
Additionally, if the secure-boot-enroll option is set to 'force' then the keys
located in the directory named 'auto' are going to be enrolled automatically. The user
is still going to be shown a screen allowing them to cancel the action if they want to,
however the enrollment will proceed automatically after a timeout without
user cancellation.
After keys are enrolled, the system reboots with secure boot enabled therefore, it is
***critical*** to ensure that everything needed for the system to boot is signed
properly (sd-boot itself, kernel, initramfs, PCI option ROMs).
This feature currently only allows loading the most simple set of variables: PK, KEK
and db.
The files need to be prepared with cert-to-efi-sig-list and then signed with
sign-efi-sig-list.
Here is a short example to generate your own keys and the right files for
auto-enrollement.
`
keys="PK KEK DB"
uuid="{$(systemd-id128 new -u)}"
for key in ${keys}; do
openssl req -new -x509 -subj "/CN=${key}/ -keyout "${key}.key" -out "${key}.crt"
openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer"
cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl.nosign"
done
sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl.nosign PK.esl
sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl.nosign KEK.esl
sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl.nosign db.esl
`
Once these keys are enrolled, all the files needed for boot ***NEED*** to be signed in
order to run. You can sign the binaries with the sbsign tool, for example:
`
sbsign --key db.key --cert db.crt bzImage --output $ESP/bzImage
`
Example:
Assuming the system has been put in Setup Mode:
`
$ESP/loader/keys/auto/db.esl
$ESP/loader/keys/auto/KEK.esl
$ESP/loader/keys/auto/PK.esl
$ESP/loader/keys/Linux Only/db.esl
$ESP/loader/keys/Linux Only/KEK.esl
$ESP/loader/keys/Linux Only/PK.esl
$ESP/loader/keys/Linux and Windows/db.esl
$ESP/loader/keys/Linux and Windows/KEK.esl
$ESP/loader/keys/Linux and Windows/PK.esl
`
If auto-enroll is set, then the db, KEK and then PK are enrolled from the 'auto'
directory.
If not, three new boot entries are available to the user in order to enroll either the
'Linux Only', 'Linux And Windows' or 'auto' set of keys.
For now, this simply outputs the PCR hash values expected for a kernel
image, if it's measured like sd-stub would do it.
(Later on, we can extend the tool, to optionally sign these
pre-calculated measurements, in order to implement signed PCR policies
for disk encryption.)
Let's grab another so far unused PCR, and measure all sysext images into
it that we load from the ESP. Note that this is possibly partly redundant,
since sysext images should have dm-verity enabled, and that is hooked up
to IMA. However, measuring this explicitly has the benefit that we can
measure filenames too, easily, and that all without need for IMA or
anything like that.
This means: when booting a unified sd-stub kernel through sd-boot we'll
now have:
1. PCR 11: unified kernel image payload (i.e. kernel, initrd, boot
splash, dtb, osrelease)
2. PCR 12: kernel command line (i.e. the one embedded in the image, plus
optionally an overriden one) + any credential files picked up by
sd-stub
3. PCR 13: sysext images picked up by sd-stub
And each of these three PCRs should carry just the above, and start from
zero, thus be pre-calculatable.
Thus, all components and parameters of the OS boot process (i.e.
everything after the boot loader) is now nicely pre-calculable.
NOTE: this actually replaces previous measuring of the syext images into
PCR 4. I added this back in 845707aae2,
following the train of thought, that sysext images for the initrd should
be measured like the initrd itself they are for, and according to my
thinking that would be a unified kernel which is measured by firmware
into PCR 4 like any other UEFI executables.
However, I think we should depart from that idea. First and foremost
that makes it harder to pre-calculate PCR 4 (since we actually measured
quite incompatible records to the TPM event log), but also I think
there's great value in being able to write policies that bind to the
used sysexts independently of the earlier boot chain (i.e. shim, boot
loader, unified kernel), hence a separate PCR makes more sense.
Strictly speaking, this is a compatibility break, but I think one we can
get away with, simply because the initrd sysext images are currently not
picked up by systemd-sysext yet in the initrd, and because of that we
can be reasonably sure noone uses this yet, and hence relies on the PCR
register used. Hence, let's clean this up before people actually do
start relying on this.
Here we grab a new – on Linux so far unused (by my Googling skills, that
is) – and measure all static components of the PE kernel image into.
This is useful since for the first time we'll have a PCR that contains
only a PCR of the booted kernel, nothing else. That allows putting
together TPM policies that bind to a specific kernel (+ builtin initrd),
without having to have booted that kernel first. PCRs can be
pre-calculated. Yay!
You might wonder, why we measure just the discovered PE sections we are
about to use, instead of the whole PE image. That's because of the next
step I have in mind: PE images should also be able to carry an
additional section that contains a signature for its own expected,
pre-calculated PCR values. This signature data should then be passed
into the booted kernel and can be used there in TPM policies. Benefit:
TPM policies can now be bound to *signatures* of PCRs, instead of the
raw hash values themselves. This makes update management a *lot* easier,
as policies don't need to be updated whenever a kernel is updated, as
long as the signature is available. Now, if the PCR signature is
embedded in the kernel PE image it cannot be of a PCR hash of the kernel
PE image itself, because that would be a chicken-and-egg problem. Hence,
by only measuring the relavent payload sections (and that means
excluding the future section that will contain the PCR hash signature)
we avoid this problem, naturally.
machine: Add APIs CopyTo[Machine]WithFlags + CopyFrom[Machine]WithFlags
- Same API to those without `WithFlags` (except this can take flags)
- Initially, only a flag to allow replacing a file if it already exists
systemd-sysctl currently fails silently under any of these conditions:
- Missing permission to write a sysctl.
- Invalid sysctl (path doesn't exists).
- Ignore failure flag ('-' in front of the sysctl name).
Because of this behaviour, configuration issues can go unnoticed as
there is no way to detect those unless going through the logs.
--strict option forces systemd-sysctl to fail if a sysctl is invalid or
if permission are insufficient. Errors on sysctl marked as "ignore
failure" will still be ignored.
While Type=file works because it seems to be the default, the line gets
ignored as printed on the stderr output.
Use the correct value "regular-file" for the target type.
A read-only /usr may ship a sysext image by default and the user wants
to opt out. Currently it's not clear how to do this.
Document that a /dev/null symlink in /etc/extensions/ works to "mask" a
sysext image in a folder with lower precedence.
While overlaying files with a sysext can be useful, it may lead to
unexpected problems depending on when a process got started and which
version of the file it gets.
Call out that overlaying files is possible but don't recommend to make
use of it.
Previous implementation of disabling rapid commit was broken, and
dropped by 308d01f3c4.
Let's re-introduce the option in the correct way, as some servers seem
to return borked message when the solicit message contain the rapid
commit option.
Closes#24065.
I had trouble finding the right paragraphs, so I guess others might have
too. Hence let's add a tiny bit more structure by separating these two
parts out.
Do not go back to disk on each selinux access, but instead cache the
label off the inode we are actually reading. That way unit file contents
and unit file label we use for access checks are always in sync.
Based on discussions here:
https://github.com/systemd/systemd/pull/10023#issuecomment-1179835586
Replaces:
https://github.com/systemd/systemd/pull/23910
This changes behaviour a bit, because we'll reach and cache the label at
the moment of loading the unit (i.e. usually on boot and reload), but
not after relabelling. Thus, users must refresh the cache explicitly via
a "systemctl daemon-reload" if they relabelled things.
This makes the SELinux story a bit more debuggable, as it adds an
AccessSELinuxContext bus property to units that will report the label we are
using for a unit (or the empty string if not known).
This also drops using the "source" path of a unit as label source. if
there's value in it, then generators should manually copy the selinux
label from the source files onto the generated unit files, so that the
rule that "access labels are read when we read the definition files" is
upheld. But I am not convinced this is really a necessary, good idea.
Estimated battery discharge rate per hour is stored in :
/var/lib/systemd/sleep/battery_discharge_percentage_rate_per_hour
This value is used to determine the initial suspend interval. In case
this file is not available or value is invalid, HibernateDelaySec
interval is used.
After wakeup from initial suspend, this value is again estimated and
written to file if value is in range of 1-199.
Logs for reference : HibernateDelaySec=15min
- Updated in /etc/systemd/sleep.conf
Jul 14 19:17:58 localhost systemd-sleep[567]: Current battery charge
percentage: 100%
Jul 14 19:17:58 localhost systemd-sleep[567]: Failed to read discharge
rate from /var/lib/systemd/sleep/batt
ery_discharge_percentage_rate_per_hour: No such file or directory
Jul 14 19:17:58 localhost systemd-sleep[567]: Set timerfd wake alarm
for 15min
Jul 14 19:33:00 localhost systemd-sleep[567]: Current battery charge
percentage after wakeup: 90%
Jul 14 19:33:00 localhost systemd-sleep[567]: Attempting to estimate
battery discharge rate after wakeup from 15min sleep
Jul 14 19:33:00 localhost systemd-sleep[567]: product_id does not
exist: No such file or directory
Jul 14 19:33:00 localhost systemd-sleep[567]: Estimated discharge rate
39 successfully updated to
/var/lib/systemd/sleep/battery_discharge_percentage_rate_per_hour
Jul 14 19:33:00 localhost systemd-sleep[567]: Current battery charge
percentage: 90%
Jul 14 19:33:00 localhost systemd-sleep[567]: product_id does not
exist: No such file or directory
Jul 14 19:33:00 localhost systemd-sleep[567]: Set timerfd wake alarm
for 1h 48min 27s
Jul 14 21:21:30 localhost systemd-sleep[567]: Current battery charge
percentage after wakeup: 90%
Jul 14 21:21:30 localhost systemd-sleep[567]: Battery was not
discharged during suspension
It is not clear what "unprivileged user namespaces are available" means.
It could mean either that they are only usable, that is, enabled in the kernel,
or they have been enabled for the specific service. Referring to the
`PrivateUsers=` options makes it clear that the latter is meant.
Since the general generator logic was established in the rewrite in
07719a21b6, generators would always write to /tmp
by default. I think this not a good default at all, because generators write a
bunch of files and would create a mess in /tmp. And for debugging, one
generally needs to remove all the files in the output directory, because
generators will complain in the output paths are already present. Thus the
approach of disabling console logging and writing many files to /tmp when
invoked with no arguments is not nice, so let's disallow operation with no
args.
But when debugging, one generally does not care about the separate output dirs
(most generators use only one). Thus the general pattern I use is something
like:
rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/{x,x,x}
This commit allows only one directory to be specified and simplifies this to:
rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/x
This is useful to use "f" or "w" to write arbitrary binary files to
disk, or files with newlines and similar (for example to provision SSH
host keys and similar).
