** Description changed: The network-interface-security upstart job unconditionally loads the usr.sbin.dhclient AppArmor profile even if the job is running in a LXC/LXD container that cannot load AppArmor policy. I don't see any negative side effects from this behavior, so I don't think this is a high priority bug. If this were to be fixed, the upstart job would need to check to see if it is running inside of a container and, if so, if the container is capable of loading its own AppArmor security policy. See https://launchpad.net/ubuntu/+source/apparmor/2.10.95-4ubuntu5 for an example of what this would look like. + + This behavior can be seen with a 16.04 host, running lxd from either the + archive or as a snap, and launching a 14.04 container. aa-status inside + of the container will show: + + $ lxd.lxc exec t aa-status + apparmor module is loaded. + 3 profiles are loaded. + 3 profiles are in enforce mode. + /sbin/dhclient + /usr/lib/NetworkManager/nm-dhcp-client.action + /usr/lib/connman/scripts/dhclient-script + 0 profiles are in complain mode. + 1 processes have profiles defined. + 1 processes are in enforce mode. + /sbin/dhclient (810) + 0 processes are in complain mode. + 0 processes are unconfined but have a profile defined. + + IMPORTANT: It is likely that upstart in 14.04 will receive a future SRU + which will result in AppArmor policy to be loaded during the boot + process when inside of a LXD container. That will make this bug more + difficult to verify. Once that change lands, you'll likely have to + modify /lib/init/aa-profile-load, inside of the container, to not load + policy at boot in order to definitively see this bug.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1640868 Title: network-interface-security upstart job is not container aware Status in ifupdown package in Ubuntu: Triaged Bug description: The network-interface-security upstart job unconditionally loads the usr.sbin.dhclient AppArmor profile even if the job is running in a LXC/LXD container that cannot load AppArmor policy. I don't see any negative side effects from this behavior, so I don't think this is a high priority bug. If this were to be fixed, the upstart job would need to check to see if it is running inside of a container and, if so, if the container is capable of loading its own AppArmor security policy. See https://launchpad.net/ubuntu/+source/apparmor/2.10.95-4ubuntu5 for an example of what this would look like. This behavior can be seen with a 16.04 host, running lxd from either the archive or as a snap, and launching a 14.04 container. aa-status inside of the container will show: $ lxd.lxc exec t aa-status apparmor module is loaded. 3 profiles are loaded. 3 profiles are in enforce mode. /sbin/dhclient /usr/lib/NetworkManager/nm-dhcp-client.action /usr/lib/connman/scripts/dhclient-script 0 profiles are in complain mode. 1 processes have profiles defined. 1 processes are in enforce mode. /sbin/dhclient (810) 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. IMPORTANT: It is likely that upstart in 14.04 will receive a future SRU which will result in AppArmor policy to be loaded during the boot process when inside of a LXD container. That will make this bug more difficult to verify. Once that change lands, you'll likely have to modify /lib/init/aa-profile-load, inside of the container, to not load policy at boot in order to definitively see this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1640868/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
