Running tasks are not subject to reloaded policies

Bug #1236455 reported by Serge Hallyn on 2013-10-07
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
AppArmor
Undecided
Unassigned
linux (Ubuntu)
High
Unassigned
Saucy
High
Unassigned
Trusty
High
Unassigned

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.

CVE References

Launchpad Janitor (janitor) wrote :

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

Changed in apparmor (Ubuntu):
status: New → Confirmed
Changed in apparmor (Ubuntu):
importance: Undecided → High
tags: added: application-confinement
Changed in apparmor (Ubuntu Saucy):
status: New → Confirmed
importance: Undecided → High
milestone: none → saucy-updates
Seth Arnold (seth-arnold) wrote :

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

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.

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

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

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

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

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

Thanks, John.

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

> 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.

Tim Gardner (timg-tpi) on 2013-11-15
Changed in apparmor (Ubuntu Saucy):
status: Confirmed → Fix Committed
Changed in apparmor:
status: New → Fix Released
no longer affects: linux
affects: apparmor (Ubuntu Saucy) → linux (Ubuntu Saucy)
Changed in linux (Ubuntu Trusty):
status: Confirmed → Fix Released
Brad Figg (brad-figg) wrote :

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!

tags: added: verification-needed-saucy
Serge Hallyn (serge-hallyn) wrote :

Verified here on saucy, thanks!

tags: added: verification-done
removed: verification-needed-saucy

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) wrote :
Download full text (13.3 KiB)

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...

Changed in linux (Ubuntu Saucy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

  • auto-apparmor Edit

Bug watches keep track of this bug in other bug trackers.