[systemd-devel] systemd-pcrlock: what prevents unauthorized changes to the NV index?

2023-12-05 Thread Demi Marie Obenour
What prevents unauthorized changes to the NV index used by
systemd-pcrlock?  Is the secret key itself stored in the NV index, with
the policy deciding who can read the key?  Or does the policy on the NV
index require that the policy established by systemd-pcrlock is itself
satisfied before the NV index can be changed?  In the latter case, does
this mean that the index can be "leaked" in certain error conditions?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab


signature.asc
Description: PGP signature


[systemd-devel] Journald Rotate

2023-12-05 Thread BARO, MAXIMO E. (KSC-COMET-6330)[COMET Primary]
Greetings,

I'm not sure if this is the right group to post this question to, but here 
goes...


  *   On my Red Hat 8 system I have Storage=persistent, SplitMode=uid and 
SystemMaxFiles=100.
  *   The folder /var/log/journal// I have 1 system.journal file 
and 99 user.journal files

When the rotate function kicks in for system.journal, does it take into account 
the 99 user files in the 100 count? Does it then at this point delete 
system.journal and create a new one?



Thank You,

Maximo E Baro
Associate Engineer IV - Comp System Admin
Jacobs Technology/COMET
[cid:image001.png@01DA2756.CBF59130]



Re: [systemd-devel] how to use systemd-sysext addons and systemd-stub to extend an UKI initrd

2023-12-05 Thread Lennart Poettering
On Mo, 04.12.23 17:40, Emanuele Giuseppe Esposito (eespo...@redhat.com) wrote:

> Hello everyone,
>
> As the title suggests, I am trying to extend an UKI initrd via
> systemd-sysext addons/extensions.
>
> I contributed to the systemd-stub UKI addons to extend the kernel
> command line, so I know how they works and planning to give a talk about
> them soon. However, I would like to get the full picture by using the
> same mechanism but with systemd-sysext addons to extend also initrd.
>
> As I understood, a systemd-sysext addon in
> /boot/efi/EFI/Linux/.efi.extra.d will be put in /.extra/sysext
> by systemd-stub, and then will be picked up by systemd-sysext to be
> added into the initrd.
>
> I am using Fedora, I created my UKI devel.efi, and made sure (just for
> safety) that the initrd contains the systemd-sysext module, as I
> generated it with dracut.
>
> The UKI is created with freshly compiled systemd-stub from commit
> 5808300c44. Kernel is 6.6.0-0.rc1.20230915git9fdfb15a3dbf.17.fc40.x86_64
>
> Then, I created a super dumb extension and put it in the right location:
> mkdir extension
> cd extension/
> vi ciao.txt
> mkdir usr
> cp ciao.txt usr/ciao2.txt
> cat /etc/os-release
> mkdir -p usr/lib/extension-release.d/
> echo ID=fedora > usr/lib/extension-release.d/extension-release.extension
> echo VERSION_ID=40 >>
> usr/lib/extension-release.d/extension-release.extension
> cat usr/lib/extension-release.d/extension-release.extension
> cd ..
> mksquashfs extension extension.raw
> mv extension.raw /boot/efi/EFI/Linux/devel.efi.extra.d/

The image must come with verity + signature, we'll not allow unsigned
extensions by default. (you could relax the image policy if you want,
or disable it but I'd advise you not to. The env var
SYSTEMD_DISSECT_VERITY_SIGNATURE=0 tells sysext to not validate images)

With upcoming systemd v255 just use "systemd-repart --make-ddi=sysext"
to generate a sysext image with verity and signing. mkosi can help you
too.

You either need to install your signature public key in the kernel's
own keychain somehow, or drop suitable certficates into
{/etc,/run}/verity.d/*.crt. The latter is a bit
underdocumented. (There was hope we could drop this again because it
would become easier to install stuff into the kernel keychain, but
that's still a mess, hence this userspace validation is probably going
to stay for good).

Ultimately if distros ship this in final products they really should
use the kernel keyring for this. That's how MSFT uses this for
example.

> Supposing I manage to do all of the above, my next question would be
> how/if to override the /lib folder instead of the traditional /usr or
> /opt, as for example I might want to add another kernel module into
> the UKI.

/lib/ is 1990's Linux. On modern distros, such as Fedora it has long
been replaced by a symlink to /usr/lib/. Hence if you want to drop
stuff into /lib/ then just drop it into /usr/lib/ instead.

> Last but not least is where is the documentation for this. I couldn't
> find anything at all about systemd-sysext, and therefore I would be very
> very happy to write (other than presenting it) some doc to make the life
> easier to anyone like me that is looking forward to using these new
> features.

So there's the man page of systemd-sysext and systemd-repart.

Flatcar has some docs:
https://www.flatcar.org/docs/latest/provisioning/sysext/

There is a video from ASG how this fits together:

https://www.youtube.com/watch?v=XTy3scX6rF4

There's no tutorial how to put this together though. Contributing that
would be very welcome of course!

Lennart

--
Lennart Poettering, Berlin


Re: [systemd-devel] Where to install UKI cmdline addons in the root partition

2023-12-05 Thread Lennart Poettering
On Mo, 04.12.23 17:48, Emanuele Giuseppe Esposito (eespo...@redhat.com) wrote:

> Hello everyone,
>
> Sorry for the back-to-back emails, but I realized I could use this
> mailing list to bring up another topic related to UKI addons.
>
> This is the same as I wrote in
> https://github.com/systemd/systemd/issues/29372 : I think we need some
> agreement to decide that if distros want to ship rpms containing default
> signed UKI addons, they should all go in the same place in the root
> partition.
>
> By putting them there, we offer the user the possibility to keep the ESP
> clean and lightweight (as there is not much space available in there
> IIRC), and the user can simply cp the addons from the root partition
> into the desired ESP to install the addon, and rm to remove them.
>
> But I still think it is important to have some agreement, and document
> it somewhere.
>
> What do you think?

I commented on the github issue. At this time I think more people are
subscribed to that than watch this ML.

Lennart

--
Lennart Poettering, Berlin