> To clarify, this is not something that can be solved upstream in apparmor, and a profile can't be accepted due to the nature of the path location?
correct, if it is a unprivileged user writable location it can't be fixed entirely upstream. It is possible for us to ship a profile that is disabled in some way but that takes a privileged user action to enable. Eg. we could ship a profile using the xattrs attachment from above, then the user would be responsible for setting the xattr with setfattr. packaging nsjail is an option for Ubuntu but like you said it wouldn't directly address previous versions and AOSP probably wouldn't like it. With that said this isn't going to be an Ubuntu only restriction, the security community in general is looking at different ways of restricting unprivileged user namespaces. SElinux has picked up some ability to mediate them, but isn't really applying it in policy yet. The OSS email list (oss-secur...@lists.openwall.com) has been discussing other options as well. The number of exploit chains associated with them has forced us to start locking them down. The AppArmor solution will be available to other distros as well, it already available upstream in the kernel and apparmor 4.0. AppArmor side there is work on aa-notify that we are looking at SRUing. That will help desktop users if they have it installed. Where they can get a notification that will take them to a simple gui that will allow them to click enable (with a password) instead of having to know the details underneath. It won't be integrated into the security center or pretty. But a little better than the current situation for the user. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2063976 Title: Apparmor breaking nsjail in AOSP Status in apparmor package in Ubuntu: New Bug description: Build sandboxing in AOSP is broken after updating to 24.04 with the following denials: [ 182.439078] audit: type=1400 audit(1714265880.641:449): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=8514 comm="nsjail" requested="userns_create" target="unprivileged_userns" [ 182.439945] audit: type=1400 audit(1714265880.642:450): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=8515 comm="nsjail" capability=6 capname="setgid" [ 182.439972] audit: type=1400 audit(1714265880.642:451): apparmor="DENIED" operation="mount" class="mount" info="failed mntpnt match" error=-13 profile="unprivileged_userns" name="/" pid=8515 comm="nsjail" flags="rw, rprivate" This seems to come from the following change earlier this year: https://gitlab.com/apparmor/apparmor/-/commit/789cda2f089b3cd3c8c4ca387f023a36f7f1738a To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2063976/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp