[apparmor] AppArmor continuing to confine process after calling rcapparmor stop

[John Johansen]

On 07/11/2014 07:21 PM, Christian Boltz wrote:
> Hello,
> 
> Am Freitag, 11. Juli 2014 schrieb Seth Arnold:
>> On Fri, Jul 11, 2014 at 04:36:03PM +0200, Miklos Szeredi wrote:
>>> I've a bug report saying that a process continues to be confined
>>> after the profile has been removed.
> 
> Feel free to CC me (I'm suse-beta [at] cboltz [dot] de in bnc), and I'll 
> have a look at it.
> 
>>> As far as my reading of the code goes, this is exactly what should
>>> happen, since common_perm() will call __aa_current_profile() which
>>> will use the obsolete profile.   Is this intentional?
>>
>> 'rcapparmor stop' doesn't unload profiles; the 'teardown' option will
>> actually unload all the profiles.
> 
> That's sounds like the Ubuntu answer ;-)
> 
> For openSUSE (and SLE 12, I assume) rcapparmor stop (which is a symlink 
> to the init script, and nowadays has some systemd magic included) will 
> unload all profiles and un-confine all processes (basically what 
> "teardown" does on Ubuntu).
> 
> rcapparmor start will load the profiles (again), but you need to restart 
> running processes to confine them again.
> 
> 
> Important note: systemd maps "restart" to "stop"/"start" instead of 
> handing over "restart" to the initscript. This means "rcapparmor 
> restart" will un-confine all running processes :-(
> 
> Use "rcapparmor reload" instead - it really "just" reloads the profiles 
> without removing confinement from running processes.
> 
> Oh, and please ask the systemd maintainers to fix
> https://bugzilla.novell.com/show_bug.cgi?id=853019 ;-)
> 
> The initscript itsself handles "restart" correctly (it behaves like 
> "reload"), but the systemd magic breaks it.
> 
Not saying that the scripting may or may not have issues. But what
Miklos is reporting is a kernel bug where the old profile continues
to be used even after it has been replaced.

This happens because the cred can't be updated, at certain points
and the kernel code falls back to the profile referenced by the cred.
However it should be doing this in an rcu_read_lock so that it find
the new version of the profile and use it safely.

There where a couple of these in the dev tree that Ubuntu is carrying
that I fixed. I wasn't aware of any in the upstream code, but I didn't
go looking either, as all the code I updated had been modified in
the dev patches. But it looks like there are a couple of these to
be fixed in the upstream code as well.