Cannot unload profile

Please provide the output of "aa-status" and the log events showing the still denied actions (see /var/log/audit/audit.log if auditd is running, /var/log/messages or, if you don't use any syslogd, "journalctl -b | grep apparmor" output).

Also check the profiles in /etc/apparmor.d/ - maybe there's another profile left that causes your problems.

# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

type=AVC msg=audit(1440783206.121:10468): apparmor="DENIED" operation="open" profile="/usr/bin/ktorrent" name="/home/petros/.kde4/share/config/kderc" pid=27211 comm="okular" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Also tried restarting kbibtex. Please note that ktorrent is *not* running, I moved its profile away from /etc/apparmor.d and no cache file exists for it.

Interesting, aa-status reports no profiles and no confined processes; are you confident that error message was after unloading the profile?

Could you include the output of:

sudo cat /sys/kernel/security/apparmor/profiles
sudo ps auxwZ | grep -v unconfined

Thanks

Yes, I've been using the system with no profiles for hours so far, and it still behaves the same way. I've tried this several times, it always behaves as if a profile were loaded in a way that is out of my control.

# cat /sys/kernel/security/apparmor/profiles
#

# ps auxwZ | grep -v unconfined
LABEL USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
#

Note that this renders use of kbibtex impossible at the moment: it cannot write to the filesystem, it cannot open okular etc and every audit message refers to the profile of ktorrent. I'm going to shut down the system in a few hours, is there anything else you'd like me to try?

This is a replacement/remove bug in the kernel. Due to how creds are set up in the kernel profile replacement is best effort, and piecemeal instead of atomic.

There are a few places where old profiles can not be updated or the replacement/removal will fail. There is a kernel patch to improve how this is handled but it is not upstream and will require a custom built kernel.

Peter, thanks so much for the quick responses; it'd probably be best to just reboot now.

I'm sorry for the inconvenience.

Thanks

I can patch and compile kernels, but probably won't have time for this over the weekend.