| 20 Feb 2023 |
 @elvishjerricco:matrix.org | zfs made a more egregious version of this mistake by including a Lua interpreter in kernel space | 09:13:32 |
| @elvishjerricco:matrix.org | like... please don't do that | 09:13:42 |
 @janne.hess:helsinki-systems.de | In reply to @elvishjerricco:matrix.org
zfs made a more egregious version of this mistake by including a Lua interpreter in kernel space I mean … still better than a fully ruby env? | 09:13:59 |
| @elvishjerricco:matrix.org | Oh no is there ruby in the kernel?? | 09:14:27 |
| @janne.hess:helsinki-systems.de | No, that's the point. Rather have lua than ruby | 09:14:41 |
| @elvishjerricco:matrix.org | ah lol fair enough | 09:14:50 |
| @janne.hess:helsinki-systems.de | Or just go the way of anti-cheat on windows and open an unauthenticated pipe and execute whatever comes out of it 🎉 | 09:15:02 |
| @janne.hess:helsinki-systems.de | * Or just go the way of anti-cheat on windows and open an unauthenticated pipe and execute whatever comes out of it in the kernel 🎉 | 09:15:11 |
| @elvishjerricco:matrix.org | oof | 09:15:12 |
| @elvishjerricco:matrix.org | The trusted boot crowd has a lot of ambition around separating root from kernel so that even root can't ruin trusted boot. I think this falls in an adjacent category; initrd shouldn't be capable of undermining system security by allowing arbitrary logic encoded at runtime | 09:17:14 |
| @elvishjerricco:matrix.org | It's.... probably not actually all that helpful | 09:17:42 |
| @elvishjerricco:matrix.org | but I can see the perspective that values it | 09:17:55 |
 @lily:lily.flowers | If your threat model just wants to avoid arbitrary execution by an attacker physically present at the machine (but cannot open the machine and muck with the electronics -- you're always screwed in that case), you really just need to ensure no custom kernel cmdline is passed in at all (like lanzaboote started doing). Also I don't think the recovery shell will run by default anyway except maybe if it makes it to rescue.target and you enter the root password (I may be misremembering that though) | 11:21:45 |
| @lily:lily.flowers | I can get the desire to want to avoid any dynamic interpretation, but if the initrd always runs the same code (and said code doesn't depend on external factors hopefully...) just restricting cmdline should handle most reasonable threat models in conjunction with secure boot/bios password/etc I feel | 11:23:52 |
| @lily:lily.flowers | (Also assuming initrd is cryptographically verified like with lanzaboote or if you are just generating UKIs or something) | 11:24:49 |
|  @mixis:bau-ha.us set a profile picture. | 18:09:05 |
| @elvishjerricco:matrix.org |
Also I don't think the recovery shell will run by default anyway
yea by default the root password isn't set, so systemd-sulogin-shell just rejects you altogether. You have to actually set it in your nixos config.
| 19:09:21 |
