[apparmor] What's about all these new "uncofined" profiles with just "userns"?

[John Johansen]

On 3/1/25 05:02, Vincas Dargis wrote:
> Hi,
> 
> After some AppArmor upgrade in Sid I've discovered that "firefox" profile is now duplicate.
> 
> Also, started to see some strange "flatpak", "busybox" errors in bash terminal...
> 
unconfined profiles shouldn't be causing errors, but if you enforce them ...

The unconfined profiles have multiple purposes/functions,

1. As a name for policy to reference. Profiles can cross reference other profiles, etc. as part of ipc rules. Instead of using unconfined for everything that isn't confined you can using an unconfined profile, giving it a name, and tightening up the profile of the application communicating with the application/service that has the unconfined profile.

Generally from a system packaging pov unconfined profiles are a stepping stone, to having a full profile.


2. They serve as a way to disable a profile without breaking policy. Simply disabling often results in the application running unconfined. But with ipc rules this can end up breaking policy. An unconfined profile fixes this problem. We did not add a symlink mechanism like disable has, as we were hoping to land an overlay mechanism that could be used instead.


3. They serve as a policy escape/by-pass for local users. If confinement is tight, an system may not have unconfined, or unconfined might have restrictions. Unconfined profiles profiles provide a way for users to create a profile, without having to go through the development work, to just allow their applications to run.

You can see this use on Ubuntu systems, where aa-notify (if enabled) will prompt the user, and then make a basic unconfined profile so that they can just run their application that is getting denials. Generally this is for AppImages atm.


4. This is being used by Ubuntu as a by-pass of the unprivileged user namespace restriction, for applications that are use unprivileged user namespaces.

    Currently Ubuntu is carrying some hard coded patches that add some restrictions on unconfined. One of those is stopping applications from using unprivileged user namespaces (privileged applications have full access). Unfortunately unprivileged user namespaces just aren't as safe as they were advertised to be and are part of most exploit chains now, but they are are used by a lot of applications, generally to setup some kind of sandbox. Instead of a big global toggle for unprivileged user namespace mitigation, Ubuntu is now doing it on a per application basis. The many of the unconfined profiles, are there to allow those applications to function while a full profile is being developed.

As for the Ubuntu unprivileged user namespace restriction. That ability will be coming to upstream as well, but as part of policy instead of hard coded. So it is taking longer to land.



> 1. Apparently, now there are bunch of new profiles, like /etc/apparmor.d/firefox, that conflicted with my own /etc/apparmor.d/usr.bin.firefox.
> 
disable the ones that conflict. An overlay feature is coming, to allow local profiles to easily override system profiles but it didn't land in 4.1

> 2. Apparently, my long-practiced "tradition" to invoke `aa-enforce /etc/apparmor.d/*` after every apparmor[-profiles] package upgrade (due to usr.bin.ping-and-friends becoming "complain" again), is now seemingly ill-advised? Enforcing all these new, almost-empty "uncofined" profiles makes sort of havoc...
> 
ah yeah aa-enforce of the unconfined profiles will cause some issues. Enough that its a bug worth fixing. We should add some kind of flag that either allows skipping those or the inverse is required to enforce on them. Opinions/feedback on which is welcome

> So,
> 
> a). Could some one please bring me back into the loop, what's it all about?
> 

> b). How should user enable proper custom firefox profile correctly?
> 
>      aa-disable /etc/apparmor.d/firefox, and enforce /etc/apparmor.d/usr.bin.firefox?
>
aa-disable of the profile file you don't want should work, and is the current recommended method. Of course it fails if they have the same file name, in which case it is recommended to rename your local version, at least until the overlay feature lands.
  
>      Or overwrite /etc/apparmor.d/firefox after every upgrade?
> 
ideally not considering that messes with packaging.

>      Or is there some sort of new overriding feature I don't know to make these new profiles inactive while custom one active?
> 
sadly the overlay feature didn't land in 4.1, it is coming and it will allow you to setup local overrides without having to overwrite profiles dropped in by packaging.

> Thanks.
> 
> 
> [0] https://salsa.debian.org/apparmor-team/apparmor/-/blob/8c785a5fb707253fb46213e0648d19b64631de83/profiles/apparmor.d/firefox
> 
> 
>