aa-logprof crash

Bug #1466812 reported by QkiZ on 2015-06-19
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
AppArmor
High
Christian Boltz
2.9
Undecided
Unassigned
apparmor (Ubuntu)
High
Ubuntu Security Team
Trusty
Undecided
Unassigned

Bug Description

aa-logprof crash after adding generic profile of apache2.
Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.
Traceback (most recent call last):
  File "/usr/sbin/aa-logprof", line 54, in <module>
    apparmor.do_logprof_pass(logmark)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2280, in do_logprof_pass
    log = log_reader.read_log(logmark)
  File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 373, in read_log
    self.add_event_to_tree(event)
  File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 278, in add_event_to_tree
    rmask = rmask.replace('c', 'w')
AttributeError: 'set' object has no attribute 'replace'

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: apparmor-utils 2.8.95~2430-0ubuntu5.2
ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
Date: Fri Jun 19 12:37:54 2015
InstallationDate: Installed on 2015-04-23 (56 days ago)
InstallationMedia: Ubuntu-Server 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1)
ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-3.16.0-30-generic root=/dev/mapper/system-root ro
SourcePackage: apparmor
Syslog:

UpgradeStatus: No upgrade log present (probably fresh install)

QkiZ (qkiz) wrote :
Seth Arnold (seth-arnold) wrote :

This line from your Dependenxies.txt indicates that one of the apparmor files has been modified; could you investigate this change? you may need to reinstall the package to get the pristine version of the file:

python3-apparmor 2.8.95~2430-0ubuntu5.2 [modified: usr/lib/python3/dist-packages/apparmor/logparser.py]

Thanks

QkiZ (qkiz) wrote :

Yes, I tested some patches but no success. aa-logprof crashes unmodified and modified with same error.

Christian Boltz (cboltz) wrote :

I can reproduce the crash with both bzr trunk and the 2.9 branch using the attached KernLog.txt

tags: added: aa-tools
Changed in apparmor:
importance: Undecided → High
Christian Boltz (cboltz) wrote :

Actually, I get a slightly different crash:

  File "/home/cb/apparmor/HEAD-clean/utils/apparmor/logparser.py", line 258, in add_event_to_tree
    rmask = rmask.replace('c', 'a')
AttributeError: 'NoneType' object has no attribute 'replace'

('NoneType' instead of 'set')

Christian Boltz (cboltz) wrote :

This log line is enough to reproduce the crash:

Jun 19 12:00:55 piorun kernel: [4475115.459952] audit: type=1400 audit(1434708055.676:19629): apparmor="ALLOWED" operation="file_perm" profile="/usr/sbin/apache2" pid=3512 comm="apache2" laddr=::ffff:193.0.236.159 lport=80 faddr=::ffff:192.168.103.80 fport=61985 family="inet6" sock_type="stream" protocol=6

which is parsed to (output of "print(e)"):
{'attr': None, 'pid': 3512, 'operation': 'file_perm', 'aamode': 'PERMITTING', 'active_hat': None, 'magic_token': 0, 'name': None, 'name2': None, 'info': None, 'profile': '/usr/sbin/apache2', 'request_mask': None, 'error_code': 0, 'task': 0, 'time': 1434708055, 'parent': 0, 'denied_mask': None, 'resource': None}

operation 'file_perm' means logparser.py will use the file-related code - but for obvious reasons, that's impossible with request_mask, denied_mask, name and name2 all being None.

John Johansen (jjohansen) wrote :

So it is possible that network, and other ipc types will show up under the "file_perm" operation. Operation is just a hint for which kernel code paths the permission request came from. Sockets certainly can be used with regular filesystem operations.

With that said, something is very wrong here. There should be request and deny masks.

Christian Boltz (cboltz) wrote :

Patch to avoid the crash (by ignoring file_perm events without request_mask):
https://lists.ubuntu.com/archives/apparmor/2015-June/008250.html

I'm also adding the aa-kernel tag because the logging seems to be broken somehow.

tags: added: aa-kernel
QkiZ (qkiz) wrote :

I applied the patch and nothing change. Error:
Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.
Traceback (most recent call last):
  File "/usr/sbin/aa-logprof", line 54, in <module>
    apparmor.do_logprof_pass(logmark)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2280, in do_logprof_pass
    log = log_reader.read_log(logmark)
  File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 378, in read_log
    self.add_event_to_tree(event)
  File "/usr/lib/python3/dist-packages/apparmor/logparser.py", line 283, in add_event_to_tree
    rmask = rmask.replace('c', 'w')
AttributeError: 'set' object has no attribute 'replace'

Christian Boltz (cboltz) wrote :

Maybe the code in the Ubuntu package needs another patch that is in upstream bzr, but not in the package. (Strictly speaking, that's not my problem - I only do the openSUSE packaging :-P)

Can you please test with a bzr checkout of the latest upstream code from lp:apparmor (trunk) and/or lp:apparmor/2.9 (2.9 branch, closer to the Ubuntu package)? You'll still need to apply the patch from comment #8.

Quick howto:
    bzr branch lp:apparmor/2.9 # or lp:apparmor for trunk
    cd $checkout_dir/utils
    # apply patch from comment #8
    python aa-logprof

BTW: Are you still testing with the same log, or with a fresh one? If it's a fresh log, please attach it so I can re-test with it.

QkiZ (qkiz) wrote :

Error:
Traceback (most recent call last):
  File "./aa-logprof", line 18, in <module>
    import apparmor.aa as apparmor
  File "/usr/local/apparmor-2.9/utils/apparmor/aa.py", line 29, in <module>
    import apparmor.logparser
  File "/usr/local/apparmor-2.9/utils/apparmor/logparser.py", line 19, in <module>
    import LibAppArmor
ImportError: No module named LibAppArmor

Fresh log: https://owncloud.qkiz.pl/index.php/s/YN51qBnQFCg8CjJ

Christian Boltz (cboltz) wrote :

Looks like python doesn't find the libapparmor bindings. Try "python3 aa-logprof" instead, maybe you have the python3 version installed. If this doesn't help, check if you have the python-libapparmor (for python2) or the python3-libapparmor (for python3) package installed.

That said - I just checked your fresh logs, and the patch from comment #8 + another pending patch from https://lists.ubuntu.com/archives/apparmor/2015-June/008249.html

Well, actually I run into another error which I just reported as https://bugs.launchpad.net/apparmor/+bug/1471425 :-/

Changed in apparmor:
assignee: nobody → Christian Boltz (cboltz)
status: New → In Progress
milestone: none → 2.9.3
QkiZ (qkiz) wrote :

Ok, I just run 'python3 aa-logprof' and have no errors. I must do some audit of apache profile and if I find any errors I will report this.

QkiZ (qkiz) wrote :

aa-logprof does not see all denied entries. For example if I switch apache to enforce mode it cant connect to MySQL.

audit: type=1400 audit(1436258489.774:2313141): apparmor="DENIED" operation="connect" profile="/usr/sbin/apache2" name="/run/mysqld/mysqld.sock" pid=24866 comm="apache2" requested_mask="wr" denied_mask="wr" fsuid=33 ouid=105

aa-logprof ignore that syslog entry.

Christian Boltz (cboltz) wrote :

Re comment #13:
Good to know, so my patch actually helps. Now Ubuntu "just" needs to release an updated package ;-)

Re comment #14:
aa-logprof (to be exact: logparser.py) assumes "connect" events are always network events, but some discussion on #apparmor (and of course your log entry) brought up that it can also happen for file sockets.

This bug is already long enough, so I opened bug 1472368 to track that ;-)

Christian Boltz (cboltz) wrote :

Fix for the utils commited to bzr (both trunk and 2.9).

For the kernel side that produces the broken log message, I just opened bug 1472776.

Changed in apparmor:
status: In Progress → Fix Committed
QkiZ (qkiz) wrote :

Thanks for help :)

Christian Boltz (cboltz) on 2015-07-14
Changed in apparmor:
milestone: 2.9.3 → 2.10
Steve Beattie (sbeattie) wrote :

AppArmor 2.10 has been released: https://launchpad.net/apparmor/2.10/2.10

Changed in apparmor:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10-0ubuntu2

---------------
apparmor (2.10-0ubuntu2) wily; urgency=medium

  * debian/patches/aa-status-dont_require_python3-apparmor.patch:
    make aa-status(8) work even when python3-apparmor is not installed,
    otherwise dh_apparmor postinst snippets can fail (LP: #1480492)
  * debian/control: make apparmor-utils depend on the same package
    version of python3-apparmor

 -- Steve Beattie <email address hidden> Fri, 31 Jul 2015 16:35:03 -0700

Changed in apparmor (Ubuntu):
status: New → Fix Released
QkiZ (qkiz) wrote :

Is that fix will be available to 14.04 LTS?

Christian Boltz (cboltz) wrote :

For the records:I accidently used --fixes lp:1466812 (= this bug) when commiting bzr trunk r3266 and 2.9 branch r2961. Those commits actually fixed bug 1509030, which is the file_inherit "twin" of this bug.

Hi guys, this looks an old bug but im still getting this behavior in 14.04.4 LTS

Will this fix make its way onto 14.04?

Cheers
Will

Mathew Hodson (mathew-hodson) wrote :

I think this bug was accidentally closed according to comment #21.

Changed in apparmor (Ubuntu):
importance: Undecided → High
status: Fix Released → Triaged
Mathew Hodson (mathew-hodson) wrote :

lp:1484217 says that this is a regression.

tags: added: regression-update
Christian Boltz (cboltz) wrote :

Please ignore comment #21 - it just says that I accidently added this bug's ID to an unrelated commit.

This bug is fixed in AppArmor 2.9.3 and 2.10, see comment #16 ;-)

I don't know if an update for Ubuntu was released, therefore I won't touch this part.

Brian Murray (brian-murray) wrote :

It doesn't seem to have been fixed in trusty.

Changed in apparmor (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Launchpad Janitor (janitor) wrote :

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

Changed in apparmor (Ubuntu Trusty):
status: New → Confirmed
Jeff Feng (jianhua) wrote :

I'm having same problem in trusty. Using apparmor 2.8.95. Hope the fix can be in this release as well.

Christian Boltz (cboltz) wrote :

"Real fix" (which decides about file vs. network instead of ignoring these events) implemented in bzr trunk r3594 (will be in 2.11) and 2.10 branch r3369 (will be in 2.10.2).

Launchpad Janitor (janitor) wrote :
Download full text (5.3 KiB)

This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5~14.04.1

---------------
apparmor (2.10.95-0ubuntu2.5~14.04.1) trusty; urgency=medium

  * Bring apparmor 2.10.95-0ubuntu2.5, from Ubuntu 16.04, to Ubuntu 14.04.
    - This allows for proper snap confinement on Ubuntu 14.04 when using the
      hardware enablement kernel (LP: #1641243)
  * Changes made on top of 2.10.95-0ubuntu2.5:
    - debian/apparmor.upstart: Remove the upstart job and continue using the
      init script in 14.04
    - debian/apparmor.postinst, debian/apparmor-profiles.postinst,
      debian/apparmor-profiles.postrm, debian/rules: Revert to using
      invoke-rc.d to load the profiles, rather than reloading them directly,
      since 14.04 will continue using the init script rather than the upstart
      job.
    - debian/apparmor.init, debian/lib/apparmor/functions,
      debian/apparmor.postinst, debian/apparmor.postrm: Remove functionality
      dealing with AppArmor policy in system image based environments since
      this 14.04 package will not need to handle such environments. This
      removes the handle_system_policy_package_updates(),
      compare_previous_version(), compare_and_save_debsums() functions and
      their callers.
    - debian/apparmor.init: Continue using running-in-container since
      systemd-detect-virt doesn't exist on 14.04
    - debian/lib/apparmor/functions, debian/apparmor.init: Remove the
      is_container_with_internal_policy() function and adjust its call sites
      in apparmor.init so that AppArmor policy is not loaded inside of 14.04
      LXD containers (avoids bug #1641236)
    - debian/lib/apparmor/profile-load, debian/apparmor.install: Remove
      profile-load as upstart's apparmor-profile-load is used in 14.04
    - debian/patches/libapparmor-mention-dbus-method-in-getcon-man.patch:
      Continue applying this patch since the dbus version in 14.04 isn't new
      enough to support fetching the AppArmor context from
      org.freedesktop.DBus.GetConnectionCredentials().
    - debian/patches/libapparmor-force-libtoolize-replacement.patch: Force
      libtoolize to replace existing files to fix a libapparmor FTBFS issue on
      14.04.
    - debian/control: Retain the original 14.04 Breaks and ignore the new
      Breaks from 2.10.95-0ubuntu2.5 since they were put in place as part of
      the enablement of UNIX domain socket mediation. They're not needed in
      this upload since UNIX domain socket mediation is disabled by default so
      updates to the profiles included in those packages are not needed.
    - Preserve the profiles and abstractions from 14.04's
      2.8.95~2430-0ubuntu5.3 apparmor package by recreating them in the
      top-level profiles-14.04/ directory of the source. They'll be installed
      to debian/tmp/etc/apparmor.d/ during the build process and then to
      /etc/apparmor.d/ on package install so that there are no changes to the
      shipped profiles or abstractions. The abstractions from
      2.10.95-0ubuntu2.5 will be installed into
      debian/tmp/snap/etc/apparmor.d/ during the build process and then into
      /etc/apparmor.d/snap/abstractions/ on package install for use wit...

Read more...

Changed in apparmor (Ubuntu Trusty):
status: Confirmed → 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