From 967d394ef4883fe72c6dbcb02f36bd61d6d4ad4f Mon Sep 17 00:00:00 2001 From: intrigeri Date: Mon, 29 Jan 2018 11:27:13 +0000 Subject: [PATCH] apparmor(7): clarify the effect of reloading a profile. LP: #1608075 Partly fixes: https://bugs.debian.org/826218 --- parser/apparmor.pod | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/parser/apparmor.pod b/parser/apparmor.pod index d614d0d00..364420510 100644 --- a/parser/apparmor.pod +++ b/parser/apparmor.pod @@ -70,9 +70,12 @@ with B<.> (except for the root B) so profiles are easier to manage (e.g. the F profile would be named F). Profiles are applied to a process at exec(3) time (as seen through the -execve(2) system call); an already running process cannot be confined. -However, once a profile is loaded for a program, that program will be -confined on the next exec(3). +execve(2) system call): once a profile is loaded for a program, that +program will be confined on the next exec(3). If a process is already +running under a profile, when one replaces that profile in the kernel, +the updated profile is applied immediately to that process. +On the other hand, a process that is already running unconfined cannot +be confined. AppArmor supports the Linux kernel's securityfs filesystem, and makes available the list of the profiles currently loaded; to mount the