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