Running tasks are not subject to reloaded policies

[Serge Hallyn]

As of saucy, if you start /usr/bin/foo under an existing policy defined
in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo
with updated permissions, then the running tasks is not subject to the
new permissions.

A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This
passes in precise, and fails in saucy.

This came up in the libvirt regression testsuite. When it tries to
virsh attach-device, then the existing libvirt task's policy must be
updated to allow it to access the new device image file. The test fails
with EACCESS trying to open the image file after loading the new policy.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Seth Arnold (seth-arnold)]

While I get the results you describe with the testcase you've provided, I don't think the description is completely accurate.

I performed my testing on:

Linux hunt 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I went far simpler:

cp /bin/bash /tmp/

Use this profile:

/tmp/bash {
  /tmp/bash rmix,
  /lib/** rm,
  /dev/tty rw,
}

apparmor_parser tmp.bash

Start the /tmp/bash shell, try to run 'ls':

bash: /bin/ls: Permission denied

Add /bin/ls rmix, to the profile
apparmor_parser --replace tmp.bash

Try ls again and you get a new error:

ls: cannot open directory .: Permission denied

Add /tmp/ r, to the profile, reload and re-ls, and it works.

[Seth Arnold (seth-arnold)]

I made some slight adjustments to test.sh and found that the sha1 of the loaded profile changes after reloading:

# ./test.sh
usr.bin.serge.allow loaded, sha1 7e932d334f64e154a8749ded59787ce0f5dc0785
usr.bin.serge.deny loaded, sha1 7045ef3e6721273fdb0bc8e556f4dd8b7136a7d7
failed

The audit messages logged at the same time:
type=AVC msg=audit(1383780124.809:900): apparmor="STATUS" operation="profile_load" parent=14173 profile="unconfined" name="/usr/bin/serge" pid=14176 comm="apparmor_parser"
type=SYSCALL msg=audit(1383780124.809:900): arch=c000003e syscall=1 success=yes exit=16785 a0=5 a1=ab8f00 a2=4191 a3=7fff0ec3b4c0 items=0 ppid=14173 pid=14176 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=pts7 comm="apparmor_parser" exe="/sbin/apparmor_parser" key=(null)
type=AVC msg=audit(1383780124.913:901): apparmor="STATUS" operation="profile_replace" parent=14173 profile="unconfined" name="/usr/bin/serge" pid=14188 comm="apparmor_parser"
type=SYSCALL msg=audit(1383780124.913:901): arch=c000003e syscall=1 success=yes exit=16953 a0=5 a1=1b58f00 a2=4239 a3=7fff4b63f570 items=0 ppid=14173 pid=14188 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=pts7 comm="apparmor_parser" exe="/sbin/apparmor_parser" key=(null)

Add these two lines after the first apparmor_parser load:
printf "usr.bin.serge.allow loaded, sha1 "
cat /sys/kernel/security/apparmor/policy/profiles/usr.bin.serge.*/sha1

Add these two lines after the second apparmor_parser load:
printf "usr.bin.serge.deny loaded, sha1 "
cat /sys/kernel/security/apparmor/policy/profiles/usr.bin.serge.*/sha1

So I think this rules out caching inconsistencies.

[Serge Hallyn (serge-hallyn)]

Quoting Seth Arnold (<email address hidden>):
> While I get the results you describe with the testcase you've provided,
> I don't think the description is completely accurate.
>
> I performed my testing on:
>
> Linux hunt 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
>
> I went far simpler:
>
> cp /bin/bash /tmp/
>
> Use this profile:
>
> /tmp/bash {
> /tmp/bash rmix,
> /lib/** rm,
> /dev/tty rw,
> }
>
> apparmor_parser tmp.bash
>
> Start the /tmp/bash shell, try to run 'ls':
>
> bash: /bin/ls: Permission denied
>
> Add /bin/ls rmix, to the profile
> apparmor_parser --replace tmp.bash
>
> Try ls again and you get a new error:
>
> ls: cannot open directory .: Permission denied
>
> Add /tmp/ r, to the profile, reload and re-ls, and it works.

I could be wrong, but I believe this test is invalid because each time
you execute /bin/ls, you are fork+exec()ing. The new task may load the
new profile. This bug is about an existing task (not) being switched to
the new profile.

(Even if you do 'exec /bin/ls /tmp' in your test - which I tried - you
are doing an exec(), which changes credentials)

[Seth Arnold (seth-arnold)]

Thanks Serge, you're right, my /tmp/bash tests indicate that the fork() + execve() works properly.

Load this profile, cd /tmp ; ./bash -- and then "echo *". You should see a "*".
/tmp/bash {
  /tmp/bash rmix,
  /lib/** rm,
  /dev/tty rw,
}

Now load this profile:
/tmp/bash {
  /tmp/bash rmix,
  /lib/** rm,
  /dev/tty rw,
  /tmp/ r,
}

"echo *" still shows "*". I'd expect the list of files in the /tmp/ directory.

Restart /tmp/bash. "echo *" will now show the files in the /tmp/ directory.

[John Johansen (jjohansen)]

I have traced this down to how the cred is being handled in a couple hooks. So dependent on program access patterns the new profile may or may not be used. I have placed a test kernel that passes serge's aa_exec test (for me) on people. Please test and confirm this kernel is working

http://people.canonical.com/~jj/linux-image-3.11.0-13-generic_3.11.0-13.20_amd64.deb
http://people.canonical.com/~jj/linux-image-extra-3.11.0-13-generic_3.11.0-13.20_amd64.deb

[Serge Hallyn (serge-hallyn)]

> http://people.canonical.com/~jj/linux-image-3.11.0-13-generic_3.11.0-13.20_amd64.deb

That passes my test case, now testing libvirt-qemu (the dup'd bug)

[Serge Hallyn (serge-hallyn)]

Great news - libvirt bug 1248577 is also fixed with this kernel!

Thanks, John.

[Luca Lazzeroni (luca-m)]

Should I try to update kernel on production machine ?

Il giorno 07/nov/2013, alle ore 16:48, Serge Hallyn <email address hidden> ha scritto:

> Great news - libvirt bug 1248577 is also fixed with this kernel!
>
> Thanks, John.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1248577).
> https://bugs.launchpad.net/bugs/1236455
>
> Title:
> Running tasks are not subject to reloaded policies
>
> Status in “apparmor” package in Ubuntu:
> Confirmed
> Status in “apparmor” source package in Saucy:
> Confirmed
> Status in “apparmor” source package in Trusty:
> Confirmed
>
> Bug description:
> As of saucy, if you start /usr/bin/foo under an existing policy defined
> in /etc/apparmor.d/usr.bin.foo, then reload /etc/apparmor.d/usr.bin.foo
> with updated permissions, then the running tasks is not subject to the
> new permissions.
>
> A testcase is at http://people.canonical.com/~serge/aa_exec.tgz . This
> passes in precise, and fails in saucy.
>
> This came up in the libvirt regression testsuite. When it tries to
> virsh attach-device, then the existing libvirt task's policy must be
> updated to allow it to access the new device image file. The test fails
> with EACCESS trying to open the image file after loading the new policy.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1236455/+subscriptions

Ing. Luca Lazzeroni - Trend Servizi Srl
Responsabile R&D
http://www.trendservizi.it

[Serge Hallyn (serge-hallyn)]

> Should I try to update kernel on production machine ?

I would suggeset waiting until the fixed kernel hits -updates. At that
point, yes, the new kernel will fix the bug for you. Until it hits
-updates I would not update a production machine to it.

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-saucy' to 'verification-done-saucy'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Serge Hallyn (serge-hallyn)]

Verified here on saucy, thanks!

[Tim Miller Dyck (timmillerdyck)]

Hi, this fixed it for me on saucy too, using linux-image-3.11.0-15-generic from -proposed. Before this kernel update, the virsh blockcopy would not work due to being blocked by apparmor.

Regards,
Tim Miller Dyck

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.11.0-15.23

---------------
linux (3.11.0-15.23) saucy; urgency=low

  [Brad Figg]

  * Release Tracking Bug
    - LP: #1259259

  [ Tim Gardner ]

  * [Config] Build-in ohci-pci
    - LP: #1244176

linux (3.11.0-15.22) saucy; urgency=low

  [Brad Figg]

  * Release Tracking Bug
    - LP: #1257092

  [ Andy Whitcroft ]

  * [Config] CONFIG_DEBUG_BUGVERBOSE=y
    - LP: #1252353

  [ Benjamin Tissoires ]

  * SAUCE: (no-up) HID: appleir: force input to be set
    - LP: #1244505

  [ John Johansen ]

  * SAUCE: (no-up) apparmor: Fix tasks not subject to, reloaded policy
    - LP: #1236455

  [ Kamal Mostafa ]

  * SAUCE: (no-up) drm/i915: i915.disable_pch_pwm overrides PCH_PWM_ENABLE
    quirk
    - LP: #1163720

  [ Manoj Iyer ]

  * SAUCE: Enable earlyprintk via the PL011.
    - LP: #1248233

  [ Paolo Pisati ]

  * [Config] armhf: RTC_DRV_PL031=y
    - LP: #1252242
  * [Config] armhf: CPU_FREQ=y && ARM_HIGHBANK_CPUFREQ=y
    - LP: #1249397

  [ Rob Herring ]

  * [Config] armhf: PSTORE_RAM=y and PSTORE_CONSOLE=y
    - LP: #1248492
  * SAUCE: net: calxedaxgmac: add mac address learning
    - LP: #1248233

  [ Tim Gardner ]

  * [Debian] Re-sign modules after debug objcopy
    - LP: #1253155

  [ Upstream Kernel Changes ]

  * Revert "rt2x00pci: Use PCI MSIs whenever possible"
    - LP: #1257037
  * Revert "epoll: use freezable blocking call"
    - LP: #1257037
  * Revert "select: use freezable blocking call"
    - LP: #1257037
  * Revert "ima: policy for RAMFS"
    - LP: #1257037
  * ARM: tlb: don't perform inner-shareable invalidation for local TLB ops
    - LP: #1239800
  * ARM: 7855/1: Add check for Cortex-A15 errata 798181 ECO
    - LP: #1239800
  * mfd: rtsx: Modify rts5249_optimize_phy
    - LP: #1255297
  * usb: musb: start musb on the udc side, too
    - LP: #1257037
  * usb-storage: add quirk for mandatory READ_CAPACITY_16
    - LP: #1257037
  * USB: support new huawei devices in option.c
    - LP: #1257037
  * USB: quirks.c: add one device that cannot deal with suspension
    - LP: #1257037
  * USB: quirks: add touchscreen that is dazzeled by remote wakeup
    - LP: #1257037
  * USB: serial: ftdi_sio: add id for Z3X Box device
    - LP: #1257037
  * xhci: Don't enable/disable RWE on bus suspend/resume.
    - LP: #1257037
  * cifs: Fix inability to write files >2GB to SMB2/3 shares
    - LP: #1257037
  * x86: Update UV3 hub revision ID
    - LP: #1257037
  * cpufreq: s3c64xx: Rename index to driver_data
    - LP: #1257037
  * cpufreq / intel_pstate: Fix max_perf_pct on resume
    - LP: #1257037
  * bcache: Fixed incorrect order of arguments to bio_alloc_bioset()
    - LP: #1257037
  * HID: wiimote: add LEGO-wiimote VID
    - LP: #1257037
  * cgroup: fix to break the while loop in cgroup_attach_task() correctly
    - LP: #1257037
  * mac80211: correctly close cancelled scans
    - LP: #1257037
  * mac80211: drop spoofed packets in ad-hoc mode
    - LP: #1257037
  * mac80211: use sta_info_get_bss() for nl80211 tx and client probing
    - LP: #1257037
  * mac80211: update sta->last_rx on acked tx frames
    - LP: #1257037
  * mac80211: fix crash if bitrate calculation goes wrong
    - LP: #1257...