On 2019-04-03 03:06:09, thighland wrote: > I encountered this issue on xenial after updating to Azure's 4.15 kernel > for testing. We started encountering an apparmor deny which doesn't > happen on the latest 4.4 kernel. I had missed setting the k flag for a > policy, and everything worked on the new kerenl once we fixed the > policy. > > Given that this bug leads to incorrect enforcement of policy does it > make sense to release a fix for xenial?
I spoke with John Johansen and Jamie Strandboge about this today. We all agree that it would be really nice to backport the fix but, unfortunately, it is also very risky. Any time that we begin mediating an operation, it requires policy to be updated to allow the operation in the appropriate profiles. This typically happens during the development cycle of Ubuntu when we are landing a new version of the kernel. This gives us sufficient testing, by the time the Ubuntu release happens, in order to sort out any problems. Also, users with custom policy have some reasonable expectation that upgrading to the new Ubuntu release or kernel version will require them to update their custom policy. In this situation, we'd be mediating locking after Ubuntu 16.04 has been released and in use for 3 years. It is quite likely to result in broken systems after the kernel update. We may be able to sort out all the problems with profiles shipped as part of the distro but obviously could not fix custom AppArmor policies that users have implemented. We'll give it some more thought to see if it is something that we can safely backport to the 4.4 kernel but at this time the feeling is that it is too likely to regress users. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1658219 Title: flock not mediated by 'k' Status in AppArmor: In Progress Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Triaged Status in linux source package in Yakkety: Won't Fix Bug description: $ cat ./apparmor.profile #include <tunables/global> profile test { #include <abstractions/base> /bin/bash ixr, /dev/pts/* rw, /usr/bin/flock ixr, # Not blocked: # aa-exec -p test -- flock -w 1 /tmp/test.lock -c true /tmp/test.lock rw, } $ sudo apparmor_parser -r ./apparmor.profile $ aa-exec -p test -- flock -w 1 /tmp/test.lock -c true && echo yes yes $ ls -l /tmp/test.lock -rw-rw-r-- 1 jamie jamie 0 Jan 20 15:57 /tmp/test.lock The flock command uses flock(LOCK_EX) and I expected it to be blocked due to the lack of 'k'. apparmor userspace 2.10.95-0ubuntu2.5 (xenial) and 4.9.0-12.13-generic kernel on amd64. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1658219/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
