On Wed, Aug 21, 2019 at 06:10:30AM +0000, Abhishek Vijeev wrote:
> profile init-systemd /lib/systemd/** flags=(complain) {
> /usr/bin/colord/** cx -> colord_profile,
> profile colord_profile flags=(complain) {
> }
> }> However the dmesg audit logs show the profile name for colord-sane as: > 'init-systemd//colord_profile//null-/usr/lib/colord/colord-sane' (sample > logs are attached for reference). We don't understand where the suffix > 'null-/usr/lib/colord/colord-sane' originates from, since we have > specified an explicit 'cx' transition for all files within > /usr/bin/colord/. Due to this problem, we are unable to confine colord > and a bunch of other processes. Your logs start after the profile transitions involved; the profile name here shows the chain of execs that were taken to reach this point: init-systemd//colord_profile//null-/usr/lib/colord/colord-sane your init-system profile executed something in /usr/bin/colord/** and then transitioned into the colord_profile child profile that process then executed /usr/lib/colord/colord-sane Because the init-systemd//colord_profile profile is in complain mode, AppArmor ALLOWED the execution and created a new //null- profile. If you take the profile out of complain mode, you'll get a DENIED when the process tries to execute a program that isn't in the profile. You can decide what profile the process should use after the exec by adding appropriate Px, Cx, ix, etc rules to the init-systemd//colord_profile profile. I hope this helps. Thanks
signature.asc
Description: PGP signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
