| Odd_Bloke | I think you can only change the kernel and initrd on PV instances, which haven't been supported for several generations of new instance type: HVM instances boot the image "normally", so the kernel/initrd in the image are used. | 15:25 |
|---|---|---|
| holmanb | @Odd_Bloke: Sure, but the point remains: user-data itself *is* priveledged. Saying that you "use userdata it to escalate priveledge" is nonsensical. | 18:08 |
| holmanb | Anything that is providing user-data *has* root, therefore anything that can be used to provide user-data to an instance must be treated as root. Exposure of the modify-instance attribute to an unpriveledged user would be the vulnerability - not anything about that user-data or cloud-init. | 18:09 |
| Odd_Bloke | Oh, yeah, sorry, it's not a vulnerability in cloud-init for sure. But as kernels and initrd aren't relevant any longer, people may think that modify-instance-attribute is only used for modifying cloud metadata about them, rather than being a vector to gain privileges on the instance itself. | 18:19 |
| minimal | well there are scenarios like c-i used with NoCloud for physical machines where anyone with physical access could stick a CIDATA CD in the machine's drive without needing root access ;-) | 18:29 |
| * minimal walks past and inserts CD into coffee holder | 18:31 | |
| * Odd_Bloke scratches out "for sure" in his previous message | 18:32 | |
| minimal | or the case of NoCloud-Net with user-data being fetches via http/https from external URLs where someone without "root" access on VM but who could gain access to server hosting the user-data could use that to gain "root" access on VM | 18:33 |
| minimal | but that's basically a "self-inflicted" security hole if you decide to rely on external user-data without being able to secure that | 18:34 |
| minimal | pytest issues now? It's all fun-and-games recently... | 19:14 |
| meena | who can reopen https://github.com/canonical/cloud-init/pull/1756 ? | 19:31 |
| -ubottu:#cloud-init- Pull 1756 in canonical/cloud-init "Feature: Kernel Modules" [Closed] | 19:31 | |
| minimal | there's a lot of distro-specific stuff in the PR | 19:42 |
| Odd_Bloke | I'm trying to think, has there ever been discussion of signed user-data? For situations where people are building their own image, configuring cloud-init to require a valid signature on user-data and baking in a certificate could solve these issues (including the server one, assuming the server isn't where the signing happens). | 19:44 |
| minimal | Odd_Bloke: I guess the assumption is that for "Clouds" it is all handled securely by the Cloud Provider's infrastructure | 19:46 |
| minimal | obviously for non-Cloud hypervisors etc that's a different matter | 19:46 |
| Odd_Bloke | I think what I'm imagining is the layer above the cloud provider's infra. Requiring signed user-data would mean that your image couldn't be passed arbitrary user-data on instance launch (or on modify-instance-attribute, more pertinently, haha), it'd have to be signed before putting it into the text box/API call/... | 19:51 |
| minimal | you'd then have the "problem" that you would need specific cloud images with the appropriate CA baked in.... | 19:53 |
| Odd_Bloke | (.../CIDATA CD :p) | 19:53 |
| Odd_Bloke | Yeah, hence my initial qualifier. Though if it existed, I guess you could bootstrap it on first boot and gain protection against modify-instance-attribute and illicit CDs. | 19:56 |
| minimal | BTW I think the LXD DS is the only one that uses vsock to obtain metadata, user-data etc via an "out-of-band" connection to a hypervisor | 20:00 |
| holmanb | Odd_Bloke: signed user-data is a neat idea | 20:31 |
| holmanb | meena: done, thanks for the ping on that | 20:32 |
| minimal | blackbox: just checking that #4772 hasn't been forgotten about | 20:35 |
| blackboxsw | minimal: thanks for the ping. I'll get on that now. had a bit of lxd/incus related issue to sort on my side to allow for better testing. Also just push up https://github.com/canonical/cloud-init/issues/4814. Thanks for the bug | 22:16 |
| -ubottu:#cloud-init- Issue 4814 in canonical/cloud-init "Schema error appears during boot regarding network v2 config with NoCloud" [Open] | 22:16 | |
| blackboxsw | meena: I'll open up 1756 . Glad to see it'll get a bit of a push there to get across the line | 22:17 |
| blackboxsw | n/m brett is on that already | 22:18 |
| minimal | blackboxsw: ah, that's a good point - is there a plan to add incus support to cc_lxd? I'm currently packaging Incus for Alpine and was wondering about c-i support for it | 23:22 |
| blackboxsw | honestly, I'll try figuring out what the position is internally before we know for sure what expectations are there. I know there is work in progress to try to remedy some of the affect of licensing changes and image hosting, but I'm not certain yet which way the wind is blowing on that. It's a reasonable question that I can promise to get back to you on. as it's annoying at the moment to try playing with both clients | 23:24 |
| blackboxsw | good ask. | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!