aa-logprof fails to track (N)amed exec in some cases

[Christian Boltz]

From the trunk r3373 commit message:

----------------------------------------------------------------------
Remove pname to bin_name mapping in autodep()

If autodep() is called with a pname starting with / (which can happen
for (N)amed exec depending on the user input), this pname is mapped to
bin_name.

This might look like a good idea, however if the given pname doesn't
exist as file on-disk, autodep() returns None instead of a (mostly
empty) profile. (Reproducer: choose (N)amed, enter "/foo/bar")

Further down the road, this results in two things:
a) the None result gets written as empty profile file (with only a "Last
   modified" line)
b) a crash if someone chooses to add an abstraction to the None, because
   None doesn't support the delete_duplicates() method for obvious
   reasons ;-)

Unfortunately this patch also introduces a regression - aa-logprof now
fails to follow the exec and doesn't ask about the log events for the
exec target anymore. However this doesn't really matter because of a) -
asking and saving to /dev/null vs. not asking isn't a real difference
;-)

Actually the patch slightly improves things - it creates a profile for
the exec target, but only with the depmod() defaults (abstractions/base)
and always in complain mode.

I'd prefer a patch that also creates a complete profile for the exec
target, but that isn't as easy as fixing the issues mentioned above and
therefore is something for a future fix.

(Note: 2.9 "only" writes an empty file and doesn't crash - but writing
an empty profile is still an improvement)
----------------------------------------------------------------------

This (especially the regression) needs to be tested again after FileRule was implemented.

[Christian Boltz (cboltz)]

Just tested again (with the "hello" script I use for the live demo in my talks) - FileRule improves things a lot.

I decided to add (via "(N)amed" exec)
  /usr/bin/cat Cx -> /foo/cat,
  /usr/bin/rm Px -> /foo/rm,

and aa-genprof created the /foo/cat child profile and the /foo/rm profile without problems, asked questions for them and added the answers to the profiles.

Unfortunately this story doesn't have a happy end yet - after choosing (F)inish, I got

  File "aa-genprof", line 160, in <module>
    apparmor.enforce(p)
  File "/home/cb/apparmor/HEAD-clean/utils/apparmor/aa.py", line 278, in enforce
    fatal_error(_("Can't find %s") % path)
  File "/home/cb/apparmor/HEAD-clean/utils/apparmor/aa.py", line 155, in fatal_error
    tb_stack = traceback.format_list(traceback.extract_stack())

Can't find /foo/rm

enforce() gets called with the profile name ("/foo/rm").

Possible fixes:
a) Calling enforce() with the profile filename ("/etc/apparmor.d/foo.rm") - boring and easy
b) make sure the new profile ("/foo/rm") can be found by name_to_prof_filename() - from looking at the code, I'd guess it doesn't work for named execs when given the profile name because of "file not found" - yeah, /foo/rm really doesn't exist... It should probably check existing_profiles before doing any other checks.

I'll have to dig a bit deeper to fix this, and it looks like it might need fixes at more than one place...