On 5/30/19 12:04 PM, Simon McVittie wrote:
On Thu, 30 May 2019 at 11:47:35 -0700, Ian wrote:
I did notice this in /var/log/syslog:

     May 30 10:46:51 1546-w-dev dbus-daemon[9496]: [system] Activating systemd
     to hand-off: service name='org.freedesktop.hostname1' unit=
     'dbus-org.freedesktop.hostname1.service' requested by ':1.21' (uid=0 pid=
     10058 comm="/usr/sbin/NetworkManager --no-daemon " label=
     "usr.sbin.NetworkManager (complain)"
This does not, in itself, indicate a bug. Whenever dbus-daemon logs an
"interesting" action like service activation, it logs all the information
it knows about the requesting process, which on AppArmor systems includes
the AppArmor label.

(complain) means the usr.sbin.NetworkManager profile is loaded in
"complain" mode, meaning that if NM does anything that would violate its
AppArmor policy, it will be logged as ALLOWED and allowed to happen,
instead of being denied. If this is not what you wanted, please look
more closely at your AppArmor policies.

     smcv

Simon, thanks for clearing that one up.

I was able to get the system to fully boot by changing

      /** Px,

to

      /** px,

in the lib.systemd.systemd post chroot profile.

The only thing outstanding is some trouble I run into after the initramfs chroot transition but before the apparmor service starts:

   May 31 12:10:55 1546-w-dev audit[5162]: AVC apparmor="ALLOWED"
   operation="exec" info="profile transition not found" error=-13
   profile="init-sys
   temd" name="/usr/bin/unshare" pid=5162 comm="(spawn)"
   requested_mask="x" denied_mask="x" fsuid=0 ouid=0
   target="/usr/bin/unshare"
   May 31 12:10:54 1546-w-dev audit[5004]: AVC apparmor="ALLOWED"
   operation="exec" info="profile transition not found" error=-13
   profile="init-sys
   temd" name="/usr/bin/unshare" pid=5004 comm="(spawn)"
   requested_mask="x" denied_mask="x" fsuid=0 ouid=0
   target="/usr/bin/unshare"


   [   42.159486] apparmor[635]:  * Starting AppArmor profiles

   [   49.102218] [5004]: failed to execute '/usr/bin/unshare'
   '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1':
   Permission denied
   [   49.106734] systemd-udevd[699]: Process '/usr/bin/unshare -m
   /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 2.

   [   49.119734] [5162]: failed to execute '/usr/bin/unshare'
   '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/dm-1':
   Permission denied
   [   49.124361] systemd-udevd[5160]: Process '/usr/bin/unshare -m
   /usr/bin/snap auto-import --mount=/dev/dm-1' failed with exit code 2.

   [  *** ] A start job is running for AppArmor initialization (15s /
   no limit)

   [   56.349850] auditd[753]: Audit daemon rotating log files
   [  OK  ] Started AppArmor initialization.

The /usr/sbin/unshare profile exists:

   root@1546-w-dev:/etc/apparmor.d# cat usr.bin.unshare
   profile usr.bin.unshare /usr/bin/unshare
   flags=(complain,attach_disconnected) {
        #include <local/whitelist>
   }


   root@1546-w-dev:/etc/apparmor.d# cat local/whitelist
        network,
        signal,
        mount,
        pivot_root,
        ptrace,
        unix,
        dbus,
        umount,
        capability,
        / mrwlk,
        /** mrwlk,
        /** px,

As does /usr/bin/snap profile:

   root@1546-w-dev:/etc/apparmor.d# cat usr.bin.snap
   profile usr.bin.snap /usr/bin/snap
   flags=(complain,attach_disconnected) {
        #include <local/whitelist>
   }

aa-status shows both of these loaded under "complain".

Is this a timing thing?  Something attempting to load as apparmor transitions? I.E. apparmor is still loading profiles when /usr/bin/unshare is being executed?

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to