| zigo | It's unclear to me: is there a fix for CVE-2024-7319 ? | 08:31 |
|---|---|---|
| tkajinam | zigo, no, but the abandon command is disabled by default. it's specific to the cloud enabling it and for abandon we do need to expose secrets so that users can get full templates | 10:16 |
| tkajinam | https://nvd.nist.gov/vuln/detail/CVE-2024-7319 | 10:16 |
| zigo | tkajinam: Right, but the functionally is important, and *we* enable it. | 10:17 |
| tkajinam | I don't know why it was reported to Red Hat product. I've seen a few people submit product CVE to get it "fixed" in upstream which is quite wired. | 10:17 |
| tkajinam | then if we "fix" it then it breaks the feature | 10:17 |
| tkajinam | we can't fix it without breaking it | 10:18 |
| tkajinam | normal users can view secrets. only admin may view it but admin user in most case has access to db so sneaking the secret in API doesn't make the situation very bad | 10:19 |
| tkajinam | normal users can view "only their own" secrets, I mean | 10:19 |
| tkajinam | and admin may view secrets for all users | 10:20 |
| tkajinam | as they can abandon stacks in any projects | 10:20 |
| zigo | Ok, I see. So it's not really a big problem right now either, is that what you're saying? | 10:20 |
| tkajinam | yes | 10:22 |
| tkajinam | it's usual "secret in API response" type of vulnerability . | 10:22 |
| pas-ha[m] | my 5c - this is a fluke due to not proper understanding of resource ownership model in OpenStack in general. In openstack MOST of the things are owned by the project (rare exceptions are e.g. app creds in keystone and keypairs in nova which are owned by the user), and that includes Heat stacks. The 'hidden parameters' feature is there to guard from unintended secret exposure, e.g. by read-only users (reader). Still, by the virtue of stack | 19:47 |
| pas-ha[m] | being owned by the project, according to default policies, any user with a sufficient role in the project (e.g. member) must be able to manipulate an existing stack in this project - update it, delete it, abandon it or adopt it. Exporting all the details of the stack (including the 'hidden' parameters) during abandon is essential to be able to re-create (adopt) this stack later. Heat has no mechanism of ascribing 'ownership' of the stack | 19:47 |
| pas-ha[m] | specifically to the user who created it. The most you could do is to limit the policy for abandon/adopt APIs to e.g. to (project) admins only. | 19:47 |
| pas-ha[m] | tkajinam: zigo ^ | 19:49 |
| pas-ha[m] | btw I once proposed a patch to nova to add some user-based access granularity (specifically to be able to limit getting vnc console url only to the user who created VM) and that was denied on the same grounds - the owning entity for instance is the project. If you want exclusive access to the user - get yourself a project where only you have roles in. | 19:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!