=== genii is now known as genii-core [04:46] Someone in #ubuntu-security mentioned that they use PXE to unlock a /boot/ encrypted system by having their router load GRUB. Can anyone explain how this works? All of the documention I've found for PXE details network OS-installs, rather than anything like remote boot and decryption. [05:26] I wonder what, if any, security benefit there is to that [05:30] mybalzitch: My impression was that it provides some remote unlocking functionality since dropbear cannot be used at this stage, or at the very least an obfuscated key stored remotely. [06:35] That would be me [06:36] It's an emergency back-up for remote devices that can lose power unexpectedly [06:40] in the 'regular' boot case, a usually unattended headless router/NAS requires LUKS secret at boot-time via serial console. If it loses power it needs to be able to reboot without waiting for the passphrase. There is a battery-backed very low power device connected to it (RasPi) that serves an alternative GRUB core image via PXE/TFTP [07:13] TJ-: Wow, ok, so the RasPi device is a PXE server which provides an alternative GRUB image that does not require password input? It is unclear to me how this works with GRUB_ENABLE_CRYPTODISK=y, as I have not seen any method of automatically providing a key/password at this early stage, except maybe for https://grub.johnlane.ie/. [07:20] ShellcatZero1: we use DRBD to mirror the router's /boot/ file-system to the raspi so at any time it has an up-to-date copy. When power is lost RasPi detects that and only then mounts the mirror as a local file-system and starts the DHCPv6/TFTP processes. The router then boots completely from the RasPi. As soon as RasPi sees the router OS is starting it stops the DHCPv6/TFTP and unmounts the [07:20] DRBD mirror [07:21] ShellcatZero1: the GRUB core loaded via PXE does not need or use LUKS [07:22] Hmm, ok [07:33] TJ-: Thanks, I believe I understand that process now. So in this process, does the RasPi have some higher boot priority in the router's GRUB, so that if the router sees your RasPi device it will PXE-boot to it, otherwise proceed with normal password-prompting boot? [07:36] ShellcatZero1: correct [07:36] but not in router's GRUB, in its firmware, the whole point is to load GRUB [07:42] TJ-: Awesome, thanks, I will probably be experimenting with this RasPi PXE setup, if you happen to have any relevant guide/documentation for it. I have really appreciated your input for this. [07:44] ShellcatZero1: the only tricky part is getting the Pi to correctly handle the DRBD secondary without allowing any writes into it (it has to be promoted to Primary when the link goes down in order to be able to mount, and returned to Secondary before the router tries to reconnect [07:46] TJ-: Yep, that part did sound tricky. === cpaelzer_ is now known as cpaelzer [12:11] icey: coreycb: jamespage: and another one, seems neutron is doing a good job keeping folk busy these days ;) https://bugs.launchpad.net/neutron/+bug/1942179 [12:12] Launchpad bug 1942179 in OpenStack Security Advisory "neutron api worker leaks memory when processing requests to not existing controllers" [Medium, Confirmed] [12:12] frickler: gah, I was about ready to pass the last one to the security team to publish :-P [12:13] ;-P [12:13] frickler: and if I'm scanning that bug correctly, it's more of a DoS vs a RCE? [12:13] icey: sorry, I'll delete my comment and resubmit it tomorrow, o.k.? [12:13] frickler: ha [12:13] icey: afaict "only" DoS, yes [12:16] frickler: I'll get it on my todo list, will discuss with others if we want to push out both together or if we should do them one at a time === genii-core is now known as genii [13:42] hey frickler - I wonder if you think a Neutron point release could happen shortly? It would be really great to be able to pick up these fixes in a point release :) [15:15] icey: I'm assuming for the recent branches this should happen soonish. but to be sure, best ask directly in the neutron channel. I'm mostly just a deployer relaying things so I don't have to patch everything myself locally ;-D [17:32] We're currently using Ubuntu 20.04 on our servers with ldap to authenticate our users. We are trying to migrate to active directory, but are running into issues with authenticating users correctly. [17:32] We have set UID numbers in active directory to be the same as in ldap, but they are not syncing across to the Ubuntu server. On 18.04 they sync correctly. We are using a Windows server 2019 backend. Has anyone run into this issue before? [17:33] kurts_allenai[m]: are the 20.04 servers able to talk to AD at all? [17:34] Yes, they're enrolling as computers fine and users are syncing over. Any attribute changes done on the AD side are not though [17:39] kurts_allenai[m]: have you looked at https://ubuntu.com/engage/microsoft-active-directory [17:44] TJ-: I've been following Microsoft's instructions previously. I'll try the Ubuntu docs and see. Thanks! [17:45] kurts_allenai[m]: not sure whether these 2 will add anything but they look to have some quality [17:46] https://ubuntu.com/server/docs/service-sssd [17:46] https://c-nergy.be/blog/?p=16472 === E_Eickmeyer is now known as Eickmeyer [20:23] TJ-: Went through the official Ubuntu doc listed above, but adcli keeps giving a "Preauthentication failed" error when I try to join the domain. Any ideas? [20:24] kurts_allenai[m]: no, but presumably that will be at the Kerberos layer; can you locate any log reports relating to that, either on the Linux client or on the AD Server ? [20:28] Not that I can find. The guide didn't say to kinit the user, so I didn't do that. Could that be the issue? [20:29] It doesn't look like the windows server blocked the authentication [20:30] I'm not sure, I try to keep away from Windows as much as possible [20:31] hello, using ubuntu 20.04 LTS and lighttpd, uh you can setup systemd to run lighttpd in a chroot of sorts yeah? [20:36] Soni: there are many ways to interpret that question. What exactly do you want to do? Is lighhttpd able to chroot itself and you want to enable that? Or do you want systemd to do the actual chroot'ing? [20:37] we'd like to use systemd to make sure lighttpd only sees a narrow view of the filesystem [20:38] systemd can also run things in containers [20:39] all the critical stuff (lighttpd config, logs) and the web content (/var/www) we guess [20:40] Soni: you can tweak the systemd unit to setup mount namespaces (see `ReadWritePaths=`, `ReadOnlyPaths=`, `InaccessiblePaths=` etc) [20:40] Soni: you could also use Apparmor to restrict what the process has access to [20:43] TJ-: Welp, kinit wasn't the solution [20:48] Soni: here's a systemd hardening example https://paste.ubuntu.com/p/SkZCQZdMr5/ [20:49] sdeziel: "you need to be logged in to view this paste"? [20:50] the pastebin was being abused; either the paster or the pastee need to be logged in to see a paste [20:51] Soni: yeah, sorry this is pretty annoying to have this behind a login. https://pastebin.com/raw/BypPcvBu should work better [20:51] sarnold: are you saying I just need to be logged in and my paste will then be public? [20:52] sdeziel: yes [20:52] sarnold: oh, that's very good news, thanks! [20:52] which is handy-ish but in practice just means I'll probably be using termbin.com a lot more :) [20:53] have you heard of instant.io? [20:53] if only I knew how to configure pastebinit [20:53] sdeziel: I tried to configure pastebinit to paste to debian's, but that's apparently busted :( [20:54] but anyway [20:54] sdeziel: that's a lot of options we don't fully understand altho we do get that there's no easy solution here [20:58] Soni: man systemd.exec has very good explanations for each of those but in your case, I think the minimum to understand would be: `ProtectHome=`, `ProtectSystem=`, `ReadWritePaths=`, `InaccessiblePaths=` and `PrivateTmp=` [21:51] how do you setup the environment, e.g. for git-receive-pack? [21:52] hmm wait there's a better way to do this isn't there