Minor apparmor problem with tor

G

glaeken2

Member
Jun 7, 2023
26
3
8
Where should I report such problems:

System logs full of:
Code: 
apparmor="DENIED" operation="create" class="net" info="failed protocol match" error=-13 profile="system_tor" pid=28980 comm="tor" family="unix" sock_type="dgram" protocol=0 requested="create" denied="create" addr=none

Related to unix socket creation under /run
Affected: every machine upgraded from proxmox 8 to 9 which has tor running
Should I report here or to debian folks?
 
Hi,
it fully depends on whether the issue occurs in Debian too. The tor package is provided by Debian, but Proxmox VE uses a different version of apparmor and the kernel. The issue doesn't seem to occur on pure Debian 13 from a quick test, so https://bugzilla.proxmox.com/ would be the right place. However, running tor on the Proxmox VE host directly is a rather uncommon use case, so I'd keep my expectations low with how quickly the issue will be looked into.
 
Yep, kernel<->apparmor incompatibility confirmed. Ubuntu vs debian. Problem occurs not only with tor.
It would be nice to have the apparmor working on the host. Especially because it's a host.
Some backporting may help. Tor can be used in multiple different ways, but maybe it's better if people haven't discovered it yet.
 
Proxmox utilizes Ubuntu’s kernels with patches for virtual machines and LXC optimizations. Consequently, AppArmor closely resembles Ubuntu rather than Debian. Therefore, the patches Ubuntu incorporated into AppArmor are the root cause of the issue.

A solution can be implemented by applying a patch to the kernel. The source code can be downloaded from https://git.proxmox.com/?p=pve-kernel.git;a=summary. Subsequently, a patch should be created and placed within the patches/kernel folder. The trixie-6.14 branch is currently the primary kernel used for Proxmox 9, while the master branch is undergoing testing of 6.17.

I am currently testing the 6.17.1-6.6 release, which incorporates my AppArmor fixes. The relevant repository is available at https://github.com/jaminmc/pve-kernel/releases/tag/6.17.1-6.6. This release addresses all the AppArmor bugs I identified during my testing of Proxmox 9. It should be regarded as an Alpha release, as the Proxmox team has not yet released a test version of 6.17.

It is worth noting that running Podman in a LXC container on ZFS will result in a kernel panic without my patches. Patch 13 specifically addresses this issue.

However, I have not yet tested TOR.
 
  • Like
Reactions: news
Hi,
jaminmc said:
I am currently testing the 6.17.1-6.6 release, which incorporates my AppArmor fixes. The relevant repository is available at https://github.com/jaminmc/pve-kernel/releases/tag/6.17.1-6.6. This release addresses all the AppArmor bugs I identified during my testing of Proxmox 9. It should be regarded as an Alpha release, as the Proxmox team has not yet released a test version of 6.17.

It is worth noting that running Podman in a LXC container on ZFS will result in a kernel panic without my patches. Patch 13 specifically addresses this issue.
Click to expand...
nice work! Would you mind submitting these patches to the development mailing list, so that all users can profit from your findings? See:
https://pve.proxmox.com/wiki/Developer_Documentation
https://pve.proxmox.com/wiki/Developer_Documentation#Software_License_and_Copyright

EDIT: okay, it seems like you are using LLMs to help you write patches. In that case it's a legal and trust gray zone, so it'll be better to properly investigate the issues ourselves. Also just to note that the tor issue is already for kernel 6.14.
 
Last edited:
Well, at least it shows where and what to
fiona said:
Hi,

nice work! Would you mind submitting these patches to the development mailing list, so that all users can profit from your findings? See:
https://pve.proxmox.com/wiki/Developer_Documentation
https://pve.proxmox.com/wiki/Developer_Documentation#Software_License_and_Copyright

EDIT: okay, it seems like you are using LLMs to help you write patches. In that case it's a legal and trust gray zone, so it'll be better to properly investigate the issues ourselves. Also just to note that the tor issue is already for kernel 6.14.
Click to expand...
Well, at least it shows where and what to patch. :)
 
jaminmc said:
Well, at least it shows where and what to

Well, at least it shows where and what to patch. :)
Click to expand...
We don't do statistical development. We actually look into problems and get to understand them. Ask the LLM to fix it 10 times (in different sessions) and you will almost surely get different responses. Are all of them correct? How would you know the one you got is? The LLM doesn't test the code it generates, of course it doesn't recompile the whole kernel just to give you a response.
 
I'm alvaro, the guy that opened this issue fiona referenced.
For the record I thought I would clarify right here as well that I believe the issue is in the kernel, not on the app armor side. Apparmor is ahead of the kernel. The Proxmox kernel (6.14.11-2-pve) rejectects the permitted operation due to missing protocol match support.
 
Last edited:
  • Like
Reactions: fiona
Adding
Code: 
abi <abi/3.0>,

profile system_tor flags=(attach_disconnected) {
....
to the beginning of /etc/apparmor.d/system_tor and running systemctl reload-or-restart apparmor.service seems to fix the issue for tor too :)
 
Is it a fix or is it a workaround for the time being, until the kernel supports ABI 4.0?

I understand it's a workaround.
 
AFAIU, the profiles should be adapted for the packages running into issues. It's just that Debian doesn't yet have the need to do so, as it ships with an older kernel and apparmor. From the Proxmox VE roadmap:

AppArmor 4​


Proxmox VE 9 ships with AppArmor version 4.1.Since this version is relatively new, you might see regressions in packages that are not part of the core Proxmox VE distribution, for example, the CUPS printing daemon.

Most issues with older profiles can be resolved by configuring AppArmor to use the 3.0 ABI by adding the abi <abi/3.0>, rule to the relevant profile. For more details, see the AppArmor Wiki.

There is also a known issue with nested containerization (e.g., Docker inside an LXC container). This issue is tracked as bug #6538.
Click to expand...
 
The PVE kernel is behind, not ahead. The problem isn’t outdated profiles, it’s that the Proxmox kernel doesn’t implement AppArmor ABI 4. The userspace tools (AppArmor 4.1.x) generate ABI 4 rules, which the kernel can’t interpret. Adding abi <abi/3.0>, doesn’t fix the issue — it only forces compatibility with an older ABI. This is a kernel–userspace mismatch, not a profile regression.
 
Last edited:
damrod said:
The PVE kernel is behind, not ahead. The problem isn’t outdated profiles, it’s that the Proxmox kernel doesn’t implement AppArmor ABI 4. The userspace tools (AppArmor 4.1.x) generate ABI 4 rules, which the kernel can’t interpret. Adding abi <abi/3.0>, doesn’t fix the issue — it only forces compatibility with an older ABI. This is a kernel–userspace mismatch, not a profile regression.
Click to expand...
What are you talking about? PVE 9 bases off a 6.14 kernel and now 6.17 as opt-in, Debian 13 bases of 6.12. And currently our kernel bases of the Ubuntu kernels, which are effectively the AppArmor upstream...

The profile need to use the correct ABI version, not stating that makes them only work by accident (also on Debian until e.g. one install a newer backports kernel)
 
  • Like
Reactions: fiona
damrod said:
The PVE kernel is behind, not ahead. The problem isn’t outdated profiles, it’s that the Proxmox kernel doesn’t implement AppArmor ABI 4. The userspace tools (AppArmor 4.1.x) generate ABI 4 rules, which the kernel can’t interpret. Adding abi <abi/3.0>, doesn’t fix the issue — it only forces compatibility with an older ABI. This is a kernel–userspace mismatch, not a profile regression.
Click to expand...
that's not true, our 6.14 kernel supports *more* than ABI 4.0 by virtue of being based on the Ubuntu kernel, which means it carries custom apparmor-upstream patches not yet mainlined. the profiles that don't work don't have an ABI specified, which means they fallback to a very old ABI, and using ABI 3.0 for those profiles usually works to make them compatible with the kernel. 4.0 profiles also work (unless they are broken for unrelated reasons, and modulo bugs, as always). these abi levels/features are unfortunately not always 100% backwards or forwards-compatible.

you can check the contents of /etc/apparmor.d/abi/3.0 , 4.0 and the output of aa-features-abi -x (which gives you what the kernel supports).
 
  • Like
Reactions: fiona
damrod said:
You are right. Sorry.
Click to expand...
don't fret - apparmor is complicated and often not easy to debug either, so misunderstanding things can easily happen.
 
  • Like
Reactions: fiona
You must log in or register to reply here.
Top Bottom