Allow write access to binfmt_misc when using Linux kernel >= 6.7

[psoftware]

Hi,
I am not sure if I found the right place where my issue lies.
Right now it seems that it is not possible to use binfmt_misc in unprivileged lxc containers, except for (read-only) mounting. I am able to mount binfmt in a lxc container, but if i write into /proc/sys/fs/binfmt_misc/register I get a permission denied error.

Since Kernel v6.7 binfmt supports namespaces, so it should be safe to use this in containers without affecting the entire machine. Is it possible to enable permissions to use binfmt for newer kernels only?

I'm actually testing this on a Proxmox machine with lxc 6.0.0 installed.

Thank you very much (:

[stgraber]

It should be possible to extend the dynamic apparmor profile generator for that.
For the static profiles, not so much as those are obviously static and so can't change based on kernel version.

[psoftware]

Thank you for your answer (:

If I understood correctly, by static profiles you mention files like this

lxc/config/apparmor/abstractions/container-base

Lines 66 to 68 in fc77e20

	# deny writes in /proc/sys/fs but allow binfmt_misc to be mounted
	mount fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/,
	deny @{PROC}/sys/fs/** wklx,

in which there can't be conditional rules based on the kernel version, right?

How does the dynamic apparmor profile generator work? Is it only used to generated static configuration files to be commited in this lxc repo, or is it supposed to be used also on the deployed systems (either at configuration or container startup time)?

Sorry for the basic questions (: I was asking this to see if I need to file a feature request to Proxmox directly rather than here :D
In their case they know the kernel version on which lxc is deployed, so maybe they can have a custom patch for their lxc to adjust the binfmt_misc rules.

Thank you again

[stgraber]

in which there can't be conditional rules based on the kernel version, right?

Correct, that's the static profile and this one can only be changed once all supported kernel version for LXC support a particular feature.

How does the dynamic apparmor profile generator work? Is it only used to generated static configuration files to be commited in this lxc repo, or is it supposed to be used also on the deployed systems (either at configuration or container startup time)?

lxc.apparmor.profile can be set to generated which then has liblxc generate a per-container profile.

You'll find the logic for that in src/lxc/lsm/apparmor.c

Sorry for the basic questions (: I was asking this to see if I need to file a feature request to Proxmox directly rather than here :D

Right, Proxmox could override the profile easily enough to add what's needed for binfmt_misc on their kernel.

[kevans1124]

Hi! We are UT Austin students doing open-source contributions for a project in a class. Are there any recent details about this issue that would be helpful? Thank you!

[stgraber]

I think what's mentioned above should still be accurate.

Basically we have logic to generate AppArmor profiles on-demand in src/lxc/lsm/apparmor.c which currently prevents accessing the binfmt filesystem.

https://github.com/lxc/lxc/blob/main/src/lxc/lsm/apparmor.c#L89

This would need to become conditional on the kernel version and then if on a recent enough kernel, block everything under @{PROC}/sys/fs/** EXCEPT for @{PROC}/sys/binfmt_misc.
The apparmor syntax to do that is quite annoying (you need to match every other path basically) but there are some examples of that in the codebase that could be used here.

[psoftware]

@stgraber Sorry for my absence. I was able to workaround this issue by copying and modifying the dynamically generated profile to add all the missing rules, using it as a static profile for my container. I still hope a fix can go upstream but I did not have time to work on it, even if now I probably know how to do it (:

@kevans1124 if you need and can be useful to you I can send you the modified profile with all the rules needed to allow binfmt to be used in lxc containers

[Blub]

@stgraber: We have lxc-default-with-{nesting,mounting} static profiles. If we were to add a flag for this to the generated profile, should there maybe also be a static lxc-default-with-binfmt-misc profile? I know adding more variants of static profiles could easily add up to a lot of files, but maybe this is something we might at some point want to move into container-base with some major release (and/or once support for it is old enough), and so could be seen as more of a feature-enablement profile?

@psoftware: Since you're running this on Proxmox VE, you don't necessarily need to use a static profile, but could just add lxc.apparmor.raw = ... lines to the container config in /etc/pve/lxc/$vmid.conf.
Although a static one will be easier to reuse for multiple containers, so might fit your use case better after all.

[tcmal]

Would someone be able to share the correct line to add to the profile, or the lxc.apparmor.raw = line for a proxmox container config?
I'm running into this when using proxmox and this configuration:

lxc.mount.entry: binfmt_misc proc/sys/fs/binfmt_misc binfmt_misc rw,create=dir
lxc.apparmor.profile: generated
lxc.apparmor.allow_nesting: 1
lxc.apparmor.raw: allow /proc/sys/fs/binfmt_misc/** rwix,

not sure if this is because .raw appends to the end of the profile?

[FernandoPicazo]

Hi, I wanted to see if I could still pick this task up?

Few questions:
Would this be a good use case for the kernel version check utility mentioned in #4569? The lxc_check_kernel_met would be exactly what we need for checking kernel version.

As for the actual mount rule all we really have to do is swap mount fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/, for something like mount options=(rw, bind) fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/,.

Would we get rid of the fstype value as well?

[dviererbe]

I was running into this issue. I was trying to cross compile with LLVM on an x86_64 host to aarch64. When installing qemu-user and binfmt-support to create an arm64 rootfs with debootstrap it failed. The underlying issue was that update-binfmts has no write access to /proc/sys/fs/binfmt_misc/status or /proc/sys/fs/binfmt_misc/register. In fact these files were not even present, see:

$ lxc launch ubuntu:24.04 noble
$ lxc shell noble
root@noble:~# apt update
root@noble:~# apt install -y qemu-user binfmt-support
root@noble:~# ls -l /proc/sys/fs/binfmt_misc/
total 0
root@noble:~# journalctl -u binfmt-support.service 
Aug 26 09:47:49 noble systemd[1]: Starting binfmt-support.service - Enable support for additional executable binary formats...
Aug 26 09:47:49 noble update-binfmts[974]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Aug 26 09:47:49 noble update-binfmts[974]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Aug 26 09:47:49 noble update-binfmts[974]: update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/register for writing: Permission denied
Aug 26 09:47:49 noble update-binfmts[974]: update-binfmts: exiting due to previous errors
Aug 26 09:47:49 noble systemd[1]: binfmt-support.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 26 09:47:49 noble systemd[1]: binfmt-support.service: Failed with result 'exit-code'.
Aug 26 09:47:49 noble systemd[1]: Failed to start binfmt-support.service - Enable support for additional executable binary formats.

Workaround

Adding the following entry to /var/snap/lxd/common/lxc/local.conf, solved this issue.

lxc.mount.entry = /proc/sys/fs/binfmt_misc proc/sys/fs/binfmt_misc none bind,rw,create=dir 0 0

System information

$ lxc --version
6.5

$ snap list lxd
Name  Version      Rev    Tracking       Publisher   Notes
lxd   6.5-72c8a10  35210  latest/stable  canonical✓  -

$ uname -a
Linux snufkin 6.14.0-27-generic #27-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 22 17:01:58 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release --all
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 25.04
Release:	25.04
Codename:	plucky