[PATCH v4 23/23] AppArmor: Remove the exclusive flag

[John Johansen]

On 6/26/19 7:22 PM, James Morris wrote:
> On Wed, 26 Jun 2019, Casey Schaufler wrote:
> 
>> With the inclusion of the "display" process attribute
>> mechanism AppArmor no longer needs to be treated as an
>> "exclusive" security module. Remove the flag that indicates
>> it is exclusive. Remove the stub getpeersec_dgram AppArmor
>> hook as it has no effect in the single LSM case and
>> interferes in the multiple LSM case.
> 
> So now if I build a kernel with SELinux and AppArmor selected, with 
> SELinux registered first, I now need to use apparmor=0 at the kernel 
> command line to preserve existing behavior (just SELinux running).
> 

AppArmor can be built-in (compiled) without being on the Enabled list.
If you had apparmor in your enabled list along with selinux before,
it would attempt to enabled and fail with the message

  exclusive disabled: apparmor

now it will be enabled but it does match what is documented in
the lsm enabled description

    A comma-separated list of LSMs, in initialization order.
    Any LSMs left off this list will be ignored. This can be
    controlled at boot with the "lsm=" parameter.


what isn't documented is the exclusive behavior and it does
make sense to have which LSMs are exclusive documented somewhere.


> This should at least be documented.
> 
> I wonder if this will break existing users, though.  Who has both 
> currently selected and depends on only one of them being active?
> 

thankfully even if you had apparmor in your lsm enabled list before,
this likely isn't enough to change the system behavior. You will
also need some apparmor policy installed and enough of the
usersoace to load it. Otherwise while apparmor will be enabled it
will come up in unconfined mode.

Even the interfaces /proc/*/attr/* will default to the first
major LSM in the list (in your example selinux). Apparmor's
labeling won't be visible without a task explicitly opting in
to it.