@pid_eins@mastodon.social
@pid_eins@mastodon.social avatar

pid_eins

@pid_eins@mastodon.social

⛵ I write software. ⛵

This profile is from a federated server and may be incomplete. Browse more on the original instance.

hughsie, to random
@hughsie@mastodon.social avatar

Can any experts explain why DynamicUser in a timer works on Fedora, but fails on every other distro we've tried? Details in https://github.com/fwupd/fwupd/pull/6178 -- thanks!

pid_eins,
@pid_eins@mastodon.social avatar

@hughsie where precisely am i supposed to look where i can see logs/output where things fail? I am a bit lost on the PR.

pid_eins, to random
@pid_eins@mastodon.social avatar

The excellent CCC VOC people published the AllSystemsGo! videos from this week. Here's the UKI talk I did there:

https://media.ccc.de/v/all-systems-go-2023-185-unified-kernel-images-ukis-

Enjoy!

pid_eins,
@pid_eins@mastodon.social avatar

And here's my other talk, about TPM2 and Linux: https://media.ccc.de/v/all-systems-go-2023-186-linux-tpms

pid_eins,
@pid_eins@mastodon.social avatar

And so many more excellent other talks: https://media.ccc.de/b/conferences/all_systems_go/asg2023

purpleidea, to random
@purpleidea@mastodon.social avatar

Honest question:

Why should we trust our TPM's to store a secret? What proves the chip maker, U.S. government, or whoever else doesn't have a backdoor API or method to get them to give up our private key?

https://www.youtube.com/watch?v=0RSH3JXqShE

/cc @pid_eins

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea nothing. Its not a binary thing of secure vs. not secure. Its a question of reducing the amount of hw/sw you have to put your trust on, and isolating key mgmt from the huge attack surface that the OS is.

There appears to be a trend btw to bring the tpm into the cpu btw, either in separate circuitry on the same chip or even in secure enclaves of the regular cpu. Which means the logic providing the (v)tpm support can then be properly reviewed/be open source.

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea enroll some other unlock mechanism, such as recovery key, password, fido2, pkcs11, ... support for that is all there.

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea @skitt the tpm is only used to unlock the root disk. If you enroll something else on the root disk you can unlock it from any other context too.

The access policy you pick for your data is up to you. If you bind access to tpm you can. If you dont want to, dont. The policy for access is entirely your domain, is under your control, not the vendor's.

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea nah, what the tpm stuff enables you to do is certainly non-interactive secure bootups. Which is great for embedded and server systems. I.e systems that have noone sitting in front of them who could type in a pw. But it is also good in case you want interactivity on unlocking: you can combine the tpm/pcr stuff with a password so that you get the guarantees the tpm is supposed to give you about hw and sw state and the benefits of a password stored in your brain if you want.

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea in fact you can even use the pcr measurements to make the system authenticate itself to you, before you type in the pw, so that you know for sure its really your unmodified laptop you are typing your secret into and not just a lookalike or a laptop that was backdoored while you were away. Tldr: no, the tpm stuff (when done correctly) should always improve security never worsen it. You make a variety of attack scenarios much harder if you bind things to the tpm, even if you...

pid_eins,
@pid_eins@mastodon.social avatar

@purpleidea ... otherwise leave your auth flow as it was.

pid_eins, to random
@pid_eins@mastodon.social avatar

Busy at the Image-Based Linux Summit, Berlin!

pid_eins, to random
@pid_eins@mastodon.social avatar

Can't wait for Wednesday, for AllSystemsGo! 2023. So many exciting talks! Have a peek at the schedule:

https://cfp.all-systems-go.io/all-systems-go-2023/schedule/

pid_eins, to random
@pid_eins@mastodon.social avatar

Exciting: → https://blogs.gnome.org/alatiera/2023/08/04/developing-gnome-os-systemd-sysext/

Foxboron, to random
@Foxboron@chaos.social avatar

It turns out 🟧 does have a lot of opinions on TPMs. A lot of them are wrong, even.

Surprised_Pikachu.jpg

pid_eins,
@pid_eins@mastodon.social avatar

@Foxboron oh god, what did you make me read?

mittorn, to random
@mittorn@masturbated.one avatar

@pid_eins
Where is now udev keymap utility?
https://kernel.googlesource.com/pub/scm/linux/hotplug/udev.git/+/28f04cff8a5b4e4dd979438b7e91732a309400e7/src/keymap/keymap.c
I still compiling it manually every time i need change keyboard mapping, especially unknown scancodes. Is there some out-of-the-box way to setup keycodes for unknown physical scancodes?

pid_eins,
@pid_eins@mastodon.social avatar

@mittorn https://github.com/systemd/systemd/blob/main/hwdb.d/60-keyboard.hwdb

pid_eins, to random
@pid_eins@mastodon.social avatar

Quick! Only three more days, and the All Systems Go! 2023 CfP ends! Submit now! https://cfp.all-systems-go.io/all-systems-go-2023/cfp ← ⚡️🏃🏻💨💨

pid_eins, to random
@pid_eins@mastodon.social avatar

Pssst! 🤫 We have an impressive systemd release v254 coming up soon! If you are curious, have a look at what's cooking here, but don't tell anyone just yet: https://raw.githubusercontent.com/systemd/systemd/main/NEWS (We hope to tag rc1 next week or the week after)

pid_eins, to random
@pid_eins@mastodon.social avatar

The AllSystemsGo! 2023 CFP ends in ⏳ ~2 weeks ⏳. Make sure to submit your talk now! 🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️ See you in Berlin! → https://all-systems-go.io/

pid_eins, to random
@pid_eins@mastodon.social avatar

interesting: https://fedoramagazine.org/use-systemd-cryptenroll-with-fido-u2f-or-tpm2-to-decrypt-your-disk/

pid_eins, to random
@pid_eins@mastodon.social avatar

@brauner and I did a talk about mounting disk images (i.e. block based file systems) in unprivileged code reasonably securely, back at LFSMMBPF in Vancouver, two weeks ago. A video of the session is now online: https://www.youtube.com/watch?v=RbMhupT3Dk4 – enjoy!

pid_eins, to random
@pid_eins@mastodon.social avatar

Here's a fun new feature we are working on in systemd: userspace-only reboot. In order to reduce grey-out times on image-based OS updates to next to nothing we are making a reboot happen where kernel stays as it is, but userspace shuts down as usual, then possibly transitions into a new rootfs, and starts up again with an initial transaction as it would on a classic system boot. During the transition selected services can pass along their fds and listening sockets, to pass "live" resources…

pid_eins,
@pid_eins@mastodon.social avatar

…from the old system to the new system. This means: super-fast switching from one OS version to the next, with all service code restarted cleanly and comprehensively, but with selected resources passed through untouched, so that they can continue to operate. And it wasn't even that hard to implement: https://github.com/systemd/systemd/pull/27435

Or in other words: let's not wait for hardware, firmware, boot loader, kernel, initrd to reinitialize on a reboot, let's just focus on userspace alone.

pid_eins,
@pid_eins@mastodon.social avatar

@juliank well, there's a rootfs pivot between the telinit steps. And its a telinit that can pass through fds for .socket units and fdstore. And there's also a "telinit u" in between. And its more than "telinit 1" btw, because we also tear down early boot.

So its considerably different actually.

pid_eins, to random
@pid_eins@mastodon.social avatar

PSA: Thou shalt not write udev rules with ACTION="add|change". Thou shalt use ACTION!="remove" instead.

If you look for "positive" events (i.e. that the device is present when it happens) then this is what you have to do. Why does this matter? Various kernel subsystems nowadays issue additional action event types (bind, unbind, …) that fire as part of device bring-up (usb…), and if your rule doesn't match on those the effect of your rules will likely be undone as these new actions are fired.

pid_eins, to random
@pid_eins@mastodon.social avatar

Now to one of the big questions of our times: what's better style? open("…", O_DIRECTORY|O_RDONLY|O_CLOEXEC) or open("…", O_DIRECTORY|O_CLOEXEC)?

Of course, both are entirely equivalent, because O_RDONLY on Linux is 0. But on a philosophical, conceptual level, what's the better way to write this?

(Asking because half of the systemd codebase does it one way, the other does it the other way.)

This is your time to shine, and contribute to the major philosophical discussion of today!

pid_eins,
@pid_eins@mastodon.social avatar

@f4grx well, you can also do fchmod() and setfattr() and whatnot. But if you are asking about read()/write(), then yes, you cannot do that, it will fail. (At least on Linux you can't). And opening a directory O_RDWR fails too.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • kavyap
  • DreamBathrooms
  • cisconetworking
  • magazineikmin
  • InstantRegret
  • Durango
  • thenastyranch
  • Youngstown
  • rosin
  • slotface
  • mdbf
  • khanakhh
  • tacticalgear
  • JUstTest
  • everett
  • modclub
  • Leos
  • cubers
  • ngwrru68w68
  • ethstaker
  • osvaldo12
  • GTA5RPClips
  • anitta
  • provamag3
  • normalnudes
  • tester
  • lostlight
  • All magazines
    •