[SOLVED] CVE-2022-0185

[Firm]

Any solutions other than set kernel.unprivileged_userns_clone to 0? Or is fixed kernel version released?

 

[t.lamprecht]

Or is fixed kernel version is released?

Yes, since last week.

For Proxmox VE 7.x, Proxmox Backup Server 2.x and Proxmox Mail Gateway 7.x:

• pve-kernel-5.13.19-3-pve in version 5.13.19-7
• pve-kernel-5.15.12-1-pve in version 5.15.12-3

For Proxmox VE 6.4, Proxmox Backup Server 1.1 and Proxmox Mail Gateway 6.4:

• pve-kernel-5.4.162-1-pve in version 5.4.162-2

Upgrade and reboot the system and you're fine.
In general please also note that this issue is mostly problematic for setups providing CT access to untrusted users or programs, just mentioning so that people can better classify how much they're actually exposed to this issue.

 

[Firm]

In general please also note that this issue is mostly problematic for setups providing CT access to untrusted users or programs, just mentioning so that people can better classify how much they're actually exposed to this issue.

I clearly understand that, just wanted to remind of the issue.

 

[filipealvarez]

Any solutions other than set kernel.unprivileged_userns_clone to 0? Or is fixed kernel version released?

Can I run this with LXC containers running ? Any side effects?

 

[t.lamprecht]

Can I run this with LXC containers running ?

Really depends on what runs in them.

Any side effects?

Again, cannot be said for the general case. It switches off user namespaces, more and more apps rely on this nowadays, albeit moreso on desktop (e.g., flatpack), but also nesting other container tech like Docker may rely on that.

Note also that user NS are just one way to exploit this, the current underlying vector is having `CAP_SYS_ADMIN`, a quite powerfull privilege that most often won't be shared much, but still, just assuming that all is 100% safe once user NS got turned off is wrong.

The safe way is to update the kernel and reboot.