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
