Hello, thanks for the info about docker - that explains why the docker profile was loaded :-) Also, upstream was fast in providing a patch that make cache write failures only a warning. I just submitted SR 561675 to get this patch into Tumbleweed. To answer your aside: Am Donnerstag, 4. Januar 2018, 00:23:31 CET schrieb Aleksa Sarai:
On 2018-01-04, Aleksa Sarai <asarai@suse.de> wrote:
As a complete aside -- there is also currently an AppArmor design flaw, where unloading a profile (ie. restarting the "AppArmor service") will make all previously confined processes unconfined -- with no way for an administrator to re-confine them (other than attaching to each process with GDB and executing aa_changehat from the context of the process).
Yes, that's why I changed apparmor.service to ExecStop=/bin/true in 2.12 to prevent that from accidently happening. This results in "restart" behaving like "reload" now. Needless to say that this is not my favorite solution. A better solution would be ExecRestart= in apparmor.service, but the systemd developers refused to implement ExecRestart= despite several people asking for it. As I already wrote two mails ago, [insert systemd rant here] ;-) (If you are interested in more details, one of the bugreports mentioned two mails ago includes the link to the discussion on systemd-devel.)
Is there a reason that restarting the "apparmor service" does anything at all? We really should not be removing profiles automatically given this fairly glaring security problem.
My straw-man pitch would be that "systemctl restart apparmor" should
For restart vs. reload, see above.
only *replace* profiles that are stored in /etc/apparmor.d. If a profile is not present in /etc/apparmor.d (and *especially* if it's currently confining a process) then the "apparmor service" should not touch it. This could be a good stop-gap until profile removal semantics are fixed in AppArmor.
This was a different problem, and should be fixed since AppArmor 2.11.1 and 2.10.3 - starting with those versions, "unknown" profiles don't get unloaded on reload. (Use aa-remove-unknown to unload profiles that don't exist in /etc/apparmor.d/) If you still can trigger this issue with current AppArmor versions, please tell me or open a bugreport. Regards, Christian Boltz -- Er wollte den Wert verändern. 0/1 sind zwei verschiedene Werte. Er kann also egal welchen Wert er vorher hatte den Wert ändern. ;-) [dfroehling in suse-programming] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org