aa-genprof will crash when select scan on Ubuntu 14.04 server

Can you please attach the backtrace? That would be more helpful than "it crashes" ;-)

BTW: does aa-logprof also crash? If yes, with the same or with a different backtrace?

The output as the following. Meanwhile, the aa-logprof will scan the syslog forever and never stop.
I have been filed the bug for aa-logprof. However, one of the developer says that the bug has been
fixed in the upstream.

----------------------------------------

samiux@croissants:~$ sudo aa-genprof suricata
Writing updated profile for /usr/bin/suricata.
Setting /usr/bin/suricata to complain mode.

Before you begin, you may wish to check if a
profile already exists for the application you
wish to confine. See the following wiki page for
more information:
http://wiki.apparmor.net/index.php/Profiles

Please start the application to be profiled in
another window and exercise its functionality now.

Once completed, select the "Scan" option below in
order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the
opportunity to choose whether the access should be
allowed or denied.

Profiling: /usr/bin/suricata

[(S)can system log for AppArmor events] / (F)inish
Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.
Traceback (most recent call last):
  File "/usr/sbin/aa-genprof", line 150, in <module>
    lp_ret = apparmor.do_logprof_pass(logmark, passno)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2246, in do_logprof_pass
    read_profiles()
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2564, in read_profiles
    read_profile(profile_dir + '/' + file, True)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2590, in read_profile
    profile_data = parse_profile_data(data, file, 0)
  File "/usr/lib/python3/dist-packages/apparmor/aa.py", line 2700, in parse_profile_data
    filelist[file]['profiles'][profile][hat] = True
TypeError: 'bool' object does not support item assignment

------------------------------------------------

That looks like a problem with reading your profiles.

Can you please attach your /etc/apparmor.d/ (as tarball)?

If you don't want to upload all your profiles, you can edit aa.py and add (above line 2700):
    print(file, profile, hat)
This should print out which profile and hat is currently being read - the last one above the backtrace should point out the profile causing the problem. Please upload at least this profile.

Attached please find the all profiles that created by crashing aa-genprof.

I can't reproduce the crash with the profiles you attached. Either there's another profile involved, or (less likely) it's something in your log.

Can you please add the "print" command to your aa.py (see comment #3) for debugging to find out which profile causes the crash?

Interesting news - I'm able to reproduce this now. The trick is to create a new profile:

rm /etc/apparmor.d/usr.bin.true
aa-genprof true
press "s"

I added the print command I proposed, and it fails at the newly created profile - print output:
    /etc/apparmor.d/usr.bin.true /usr/bin/true /usr/bin/true

The autodep code fills "filename" with a wrong structure with a level missing.
For comparison see the (heavily formatted) output of print(filelist)

'/etc/apparmor.d/usr.bin.true': defaultdict (
    <function hasher at 0x7f32630b8d08>, {'profiles': defaultdict (
        <function hasher at 0x7f32630b8d08>, {'/usr/bin/true': True}
    ), 'include': defaultdict (
        <function hasher at 0x7f32630b8d08>, {'tunables/global': True}
    )}
),

'/etc/apparmor.d/usr.lib.dovecot.dict': defaultdict (
    <function hasher at 0x7f32630b8d08>, {'profiles': defaultdict (
        <function hasher at 0x7f32630b8d08>, {'/usr/lib/dovecot/dict': defaultdict (
            <function hasher at 0x7f32630b8d08>, {'/usr/lib/dovecot/dict': True}
        )}
    ), 'include': defaultdict (
        <function hasher at 0x7f32630b8d08>, {'tunables/global': True}
    )}
),

(we really need to document the internal structure of our more interesting[tm] variables ;-)

Now that we know what is wrong, fixing it (in aa.py / autodep) is easy - even at 3 am ;-)

Can you please test the following patch?

=== modified file 'utils/apparmor/aa.py'
--- utils/apparmor/aa.py 2014-04-26 11:05:55 +0000
+++ utils/apparmor/aa.py 2014-05-19 00:51:04 +0000
@@ -583,7 +583,8 @@
         if not filelist.get(file, False):
             filelist[file] = hasher()
         filelist[file]['include']['tunables/global'] = True
- filelist[file]['profiles'][pname] = True
+ filelist[file]['profiles'][pname] = hasher()
+ filelist[file]['profiles'][pname][pname] = True
     write_profile_ui_feedback(pname)

 def get_profile_flags(filename, program):

Funnily I added the line to blame myself - but without it, autodep was even more buggy ;-) (bzr log -r2396 if you are interested in details)

It is interesting that I cannot locate the aa.py at utils/apparmor directory.

However, I find it at /usr/lib/python3/dist-packages/apparmor/aa.py.

What can I do now?

Try this:

sudo -s
cd /usr/lib/python3/dist-packages/
patch --dry-run -p1
<paste the diff, from the === line to the "def get_profile..." line -- including both>
hit ^D

If that worked, re-run the patch command without --dry-run, then start testing.

If it didn't work, then edit /usr/lib/python3/dist-packages/apparmor/aa.py, look about 583 lines into the file, and try making the edits by hand. Note that Python is very picky about whitespace, it'd be best to use something like vim's :set list feature to make sure you use the same tabs or spaces as surrounding code. (Which is why I suspect the patch will fail. Web browsers aren't very good at whitespace.)

Thanks

After the change at aa.py, the aa-genprof with scan option will not crash in the first run.

However, when I select "scan" again instead of "finish", it go to scan the syslog and it crashes when it find something to add to the other profile.

This means my patch is at least an improvement ;-)

Can you please paste the new backtrace?

(For the records: I commited the patch from comment 7 to AppArmor bzr trunk r2516)

I'm closing this bug as fixed because the problem you initially reported is fixed in bzr r2516.

If you can reproduce the backtrace you mentioned in comment #10, please open a new bugreport.

Hi, this makes aa-genprof mostly unusable for Ubuntu 14.04; any chance of an SRU with the fix?

The upstream fix is r2516. The fix was released in Utopic with apparmor 2.8.96~2541-0ubuntu1. The fix has not reached 14.04, but should be SRU'ed (along with quite a few other aa.py fixes).

Apparmor 2.9.0 has been released; closing.

I don't think this was ever SRUed to trusty, so the the Trusty task shouldn'e be marked Fix Released.

The fix was released in Utopic with apparmor 2.8.96~2541-0ubuntu1, but Trusty is still on 2.8.95~2430-0ubuntu5.

I have reproduced the traceback with apparmor 2.8.95~2430-0ubuntu5.1 from trusty-updates, and can confirm that apparmor 2.8.95~2430-0ubuntu5.2 from trusty-proposed fixes the problem. Marking verification-done.

I have reproduced the traceback when profiling empathy with apparmor 2.8.95~2430-0ubuntu5.1 from trusty-updates, and can confirm that apparmor 2.8.95~2430-0ubuntu5.2 from trusty-proposed fixes the problem. Marking verification-done.

Bah, my apologies, posted to the wrong bug report.

So, yah. I'm getting this error.

But I'm on 14.04 LTS. It's still running the malfunctioning Apparmor 2.8.95~2430. It seems then that fix 2.8.96~2541 was never issued.

Apparmor seems impotent. It seems as though it is impossible to configure, impossible to use Apparmor to secure a machine running Ubuntu 14.04. Ubuntu 14.04 LTS must therefore be inherently insecure. Otherwise Apparmor wouldn't be necessary in the first place. Ubuntu Trusty can't be trusted. Ha ha.

The Ubuntu download page says: "Ubuntu 14.04.2 LTS comes with five years of security and maintenance updates, guaranteed."

Is that, like, sales twaddle? Do you remember the days when the Linux crowd used to jeer endlessly at Microsoft security flaws: "Meh, Microsoft is like sooo rubbish and Linux is sooo superior blah blah twaddle".

So this is now a year since "Trusty" was released, and eight months since the Apparmor bugfix was released.

And users are still wasting time trying to get Apparmor to work, wasting time reporting the bug.

How much time do linux users waste reporting bugs that have already been fixed but haven't been implemented? You can wave goodbye to a day going through the process of trying to learn how to use some arcane linux package, discover it doesn't work, report the bug, and it all be an utter waste of time because nobody is listening. You can wave goodbye to hours just getting to grip with and reporting a bug. It happens all the time. Linux users must be [insert censored word here] because they have nothing else to do with their free time but wrestle with malfunctioning software and report bugs. They have no lives. What's worse their efforts are utterly futile. They are [insert censored word here].

If the Apparmor fix isn't being added to Ubuntu 14.04, then why not disable Apparmor in the release so people don't waste time trying to get it to work?

There is an apparmor update working its way through the SRU process http://bugs.launchpad.net/bugs/1449769

Bravo.

This is an issue for new users, btw, because the rather well written "Introduction to Apparmor" by Bodhi.Zazen on Ubuntu Forums (http://ubuntuforums.org/showthread.php?t=1008906) uses Genprof at the crucial point where its tutorial teaches you how to build a profile. And it makes a special point of doing this for Firefox, which is arguably the main reason why any desktop user would seek to configure Apparmor when they learned of its existence. So Bodhi.Zazen's tutorial goes kaput just at the point where you are beginning to feel you are making real progress toward securing your machine. (It's seven year's old anyway, yet prominent in the search engines and a big draw because it's a reasonably good tutorial - a rare thing).

If users understood that Apparmor's out-of-the-box profiles should give reasonable-enough protection (they should, shouldn't they? they do, don't they?), they might get a night's sleep. Or perhaps after a user learns from Bodhi.Zazen that they need to install Apparmor's package of pre-baked profiles separately (this is necessary, isn't it?), it might dawn on them that this really is protection enough to give them a night's sleep (it is, isn't it?). But the case is not clear. And the Firefox profile is disabled by default. So that brings you back to Bodhi.Zazen's kaput tutorial and the Apparmor bug. Aggh!

This bug was fixed in the package apparmor - 2.8.95~2430-0ubuntu5.2

---------------
apparmor (2.8.95~2430-0ubuntu5.2) trusty-proposed; urgency=medium

  * debian/patches/php5-Zend_semaphore-lp1401084.patch: allow php5
    abstraction access to Zend opcache files (LP: #1401084)
  * debian/patches/dnsmasq-lxc_networking-lp1403468.patch: update
    profile for lxc support (LP: #1403468)
  * debian/patches/profiles-texlive_font_generation-lp1010909.patch:
    allow generation of texlive fonts by sanitized-helpers
    (LP: #1010909)
  * debian/apport/source_apparmor.py: fix the apparmor apport hook
    so it does not raise an exception if a non-unicode character is
    found in /var/log/kern.log or in /var/log/syslog. This should
    work under python3 or python2.7 (LP: #1304447)
  * debian/patches/profiles-dovecot-updates-lp1296667.patch: update
    dovecot profiles to address several missing permissions.
    (LP: #1296667)
  * debian/patches/profiles-adjust_X_for_lightdm-lp1339727.patch:
    adjust X abstraction for LightDM xauthority location (LP: #1339727)
  * debian/patches/libapparmor-fix_memory_leaks-lp1340927.patch; fix
    memory leaks in log parsing component of libapparmor (LP: #1340927)
  * debian/patches/libapparmor-another_audit_format-lp1399027.patch:
    add support for another log format style (LP: #1399027)
  * debian/patches/tests-workaround_for_unix_socket_change-lp1425398.patch:
    work around apparmor kernel behavioral change in regression tests
    (LP: #1425398)
  * debian/control: add breaks on python3-apparmor against older
    apparmor-utils that used to be where python bits lived
    (LP: #1373259)
  * debian/patches/utils-update_to_2.9.2.patch: update the python
    utilities to the upstream 2.9.2 (LP: #1449769, incorporating a
    large number of fixes and improvements, including:
    - fix aa-genprof traceback with apparmor 2.8.95 (LP: #1294797)
    - fix aa-genprof crashing when selecting scan on Ubuntu 14.04 server
      (LP: #1319829)
    - make aa-logprof read profile instead of program binary
      (LP: #1317176, LP: #1324154)
    - aa-complain: don't traceback when marking multiple profiles
      (LP: #1378095)
    - make python tools able to parse mounts with UTF-8 non-ascii
      characters (LP: #1310598)

 -- Steve Beattie <email address hidden> Thu, 30 Apr 2015 12:18:08 -0700

The verification of the Stable Release Update for apparmor has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.