[apparmor] profiles cannot be deleted

[John Johansen]

On 12/20/2013 02:02 AM, Aaron Lewis wrote:
> Hi John
> 
> Thanks for the quick reply, I'm going to try that next time I
> encounter certain situations
> 
I think there is a script floating around somewhere to help clean
these out. I will poke

> It seems like if the file gets deleted, the rules became a mess.
> 
I'm not sure I follow.

However this MIGHT help explain. The files in /etc/apparmor.d/
or where ever your profiles are stored don't really follow what is
in the kernel. They need to be synced when changes are made, and
this is what the init scripts try to do (well at least reload).
It looks at what is in the kernel and what is in the profiles
directory, and diffs them.

It should replace any that are in both, load new ones from the
directory and remove profiles that are in the kernel but not
in the directory. Of course there are exceptions and depending
on your distro their may be dynamically generated profiles. eg
Ubuntu is using generated profiles for libvirt, click packages,
and in some cases lxc.

When a profile is replaced, it is only replaced on the tasks
that it is currently on. So replacing
/opt/cisco/anyconnect/bin/vpnagentd will result in all tasks
confined by that profile being updated. However the tasks
with the learning profiles
  /opt/cisco/anyconnect/bin/vpnagentd//null-1  ...
don't get updated.

This is because the transition is not known, and the learning
tools should do a manual replacement based on the choice that
was made eg. if ix was used 
  /opt/cisco/anyconnect/bin/vpnagentd//null-1
would get replaced with
  /opt/cisco/anyconnect/bin/vpnagentd
where px would result in a different profile.

Currently the tools (and kernel) don't handle this form of
replacement correctly. The old interface that supported this
had to be removed due to kernel changes and the new interface
isn't properly supported yet (there has been work to fix
this just not all the pieces have landed yet).

This will however still rely on manual tool based updates.
I do have a plan to enable a kernel based update. So that
when the profile in learning mode is replace eg.
  /opt/cisco/anyconnect/bin/vpnagentd
its children null-1, ... are re-evaluated based on any new
transitions, and can also be automatically replaced. This won't
get everything but this + fixed reference counting will fix most
of the issues we see today.


Now on to removal, when a profile is removed it is replaced
by the default profile (unconfined). So enforcement of its
rules will stop and to get enforcement to happen for the task
again, the process must be stopped and restarted. Loading of
a new profile will not confine the running task.

In the future we may pickup the ability to manually reconfine
a task, and we will be able to replace an existing profile with
a profile in unconfined mode instead of removing it. Which would
make it possible to force a task back into confinement without
restarting it. However its children during the period the task
was unconfined may pick-up different confinement than the
profile would indicate. So restarting a service would still be
the safe thing to do.

> 
> On Fri, Dec 20, 2013 at 5:45 PM, John Johansen
> <john.johansen at canonical.com> wrote:
>> On 12/20/2013 01:22 AM, Aaron Lewis wrote:
>>> Hi,
>>>
>>> I couldn't delete profiles, in aa-status I see bunches of lines like this,
>>>
>>> 188 profiles are in complain mode.
>>>    /opt/cisco/anyconnect/bin/vpnagentd//null-1
>>>    /opt/cisco/anyconnect/bin/vpnagentd//null-10
>>>    /opt/cisco/anyconnect/bin/vpnagentd//null-11
>>>    /opt/cisco/anyconnect/bin/vpnagentd//null-12
>>>    /opt/cisco/anyconnect/bin/vpnagentd//null-13
>>>    /opt/cisco/anyconnect/bin/vpnagentd//null-14
>>>
>> This are learning profiles that are created when a profile in complain mode
>> does an exec and the current profile does not have a rule to cover the
>> transition.
>>
>> They where supposed to be auto-delete/remove profiles so that they would
>> be reaped as soon as the last reference to them was removed. However due to
>> current limitations in the ref counting that does not happen yet.
>>
>> This is one of the things that should be fixed in the 3.0 release
>>
>>> I have to reboot to clear them out.
>>>
>>
>> if you do
>>   echo -n "/opt/cisco/anyconnect/bin/vpnagentd/null-10" >/sys/kernel/security/apparmor/.remove
>>
>> does this correctly remove the profile for you?
>>
> 
> 
>