aa-logprof crash

[QkiZ]

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)

[Seth Arnold (seth-arnold)]

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)]

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

[Christian Boltz (cboltz)]

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

[Christian Boltz (cboltz)]

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)]

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)]

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)]

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.

[QkiZ (qkiz)]

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)]

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)]

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)]

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 :-/

[QkiZ (qkiz)]

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)]

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)]

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)]

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.

[QkiZ (qkiz)]

Thanks for help :)

[Steve Beattie (sbeattie)]

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

[Launchpad Janitor (janitor)]

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

[QkiZ (qkiz)]

Is that fix will be available to 14.04 LTS?

[Christian Boltz (cboltz)]

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.

[[e-mail] (william20111)]

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 (mhodson)]

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

[Mathew Hodson (mhodson)]

lp:1484217 says that this is a regression.

[Christian Boltz (cboltz)]

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)]

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

[Launchpad Janitor (janitor)]

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

[Jeff Feng (jianhua)]

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)]

"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)]

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