update AppArmor rules of interfaces for flock for new 4.4 SRU kernel

[Robert Liu]

The 4.4 kernel now has landed the fix for bug #1658219. However, it causes flock calls of interfaces blocked. Because they don't declare 'k' flag in their rules. For example, the network-manager interface declare this:
    /run/resolvconf/** w,
Previously, network-manager can lock /run/resolvconf/run-lock without any problem. But after upgrade kernel to 4.4.0-160.188, it stops working.

The testing environment is an armhf device with Ubuntu Core 16 and network-manager 1.2.2-22. The new kernel is a derivative kernel based on 4.4.0-160.188.
In core snap, /sbin/resolvconf will use /run/resolvconf/run-lock when update the content of resolv.conf. In NM-1.10, it uses its own resolvconf script which doesn't use the lock file.

A workaround is to update the rule in /var/lib/snapd/apparmor/profiles/snap.network-manager.networkmanager to '/run/resolvconf/** wk,' manually.

I suppose we need to update these kind of interfaces/rules, otherwise, once the series of kernel released, there will be more this kind of issues happen.

Also, I would like to know when we update the rules in snapd, will it update/re-generate all existing rules? My concern is that we need to find ways to update the existing profiles of running devices.

here are snippets of strace output. They were captured on a armhf device with 4.4.0-168.188 based kernel.
nm-strace.log.10968:open("/run/resolvconf/run-lock", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
nm-strace.log.10968-fcntl64(9, F_DUPFD, 10) = -1 EBADF (Bad file descriptor)
nm-strace.log.10968-dup2(3, 9) = 9
nm-strace.log.10968-close(3) = 0
nm-strace.log.10968-stat64("/sbin/flock", 0x7ebc02e0) = -1 ENOENT (No such file or directory)
nm-strace.log.10968-stat64("/bin/flock", 0x7ebc02e0) = -1 ENOENT (No such file or directory)
nm-strace.log.10968-stat64("/usr/bin/flock", {st_mode=S_IFREG|0755, st_size=18208, ...}) = 0
nm-strace.log.10968-clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x76f00068) = 10972
nm-strace.log.10968-wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 65}], 0, NULL) = 10972
nm-strace.log.10968---- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10972, si_uid=0, si_status=65, si_utime=0, si_stime=2} ---
nm-strace.log.10968-sigreturn({mask=[]}) = 10972

nm-strace.log.10972-timer_create(CLOCK_MONOTONIC, {sigev_signo=SIGALRM, sigev_notify=SIGEV_SIGNAL}, [0]) = 0
nm-strace.log.10972-timer_settime(0, 0x4 /* TIMER_??? */, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=10, tv_nsec=0}}, NULL) = 0
nm-strace.log.10972:flock(9, LOCK_EX) = -1 EACCES (Permission denied)
nm-strace.log.10972:write(2, "flock: ", 7) = 7
nm-strace.log.10972-write(2, "9", 1) = 1
nm-strace.log.10972-write(2, ": ", 2) = 2
nm-strace.log.10972-open("/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
nm-strace.log.10972-open("/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
nm-strace.log.10972-open("/usr/share/locale/C/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
nm-strace.log.10972-open("/usr/share/locale-langpack/C.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
nm-strace.log.10972-open("/usr/share/locale-langpack/C.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
nm-strace.log.10972-open("/usr/share/locale-langpack/C/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
nm-strace.log.10972-write(2, "Permission denied\n", 18) = 18

[daniel CURTIS (anoda)]

Hello.

I would like to note, that when Linux kernel has been updated to 4.4.0-160.188 version[1] (with, among others, patches for LP:#1658219 and LP:#1838090), I've had to update a few profiles (such as Audacious, Parole, Xorg, Logrotate etc.), because of a lot of "DENIED" entries in system log files. If it's about access controls (vide 'requested{denied}_mask'): most new rules required 'm' (memory map as executable), but some of them needed 'k' (file locking) etc.)

However, it seems everything is okay now and I hope, that there will be no such issues anymore. Anyway, Mr Tyler Hicks was right: "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".

By the way; what is an impact of these changes? (I mean LP:#1658219 and LP:#1838090 patches). Does it means, that now, use of 'm' and 'k' access is correctly secured/restricted/checked by AppArmor and kernel?

Thanks, best regards.
_____________________
[1] https://launchpad.net/ubuntu/+source/linux/4.4.0-160.188

[Jamie Strandboge (jdstrand)]

The snapd rules are currently shared across all kernels so the rules would have been run under any kernel with the flock change (ie, later than 4.4). While it was known that the 4.4 SRU kernel made this change, it was expected that snapd bugs would be shallow; it looks like this is one of those bugs. I've created the following PRs for this:

* https://github.com/snapcore/snapd/pull/7300
* https://github.com/snapcore/snapd/pull/7301

The second will be in 2.41 which the snapd team is working on releases right now.

[Michael Vogt (mvo)]

I added some comments into https://bugs.launchpad.net/apparmor/+bug/1658219 what we can do here to ensure we don't brick devices with this upgrade.