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

Bug #1840873 reported by Robert Liu on 2019-08-21
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
High
Unassigned

Bug Description

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

Robert Liu (robertliu) on 2019-08-21
description: updated
daniel CURTIS (anoda) wrote :

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) wrote :

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.

Changed in snapd:
importance: Undecided → High
status: New → In Progress
summary: - Need updating AppArmors rules of interfaces for flock
+ Need updating AppArmor rules of interfaces for flock
summary: - Need updating AppArmor rules of interfaces for flock
+ update AppArmor rules of interfaces for flock for new 4.4 SRU kernel
Changed in snapd:
status: In Progress → Fix Committed
milestone: none → 2.41
Michael Vogt (mvo) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers