Comment # 14 on bug 1065388 from Christian Boltz

Created attachment 746220 [details]
updated /etc/apparmor.d/usr.bin.lessopen.sh profile

OK, here we go.

Let me start with the easy part:

As you noticed, groff wants to execute several helper binaries:
  operation="exec" name="/usr/bin/eqn" comm="groff" 
  operation="exec" name="/usr/bin/grotty" comm="groff" 
  operation="exec" name="/usr/bin/pic" comm="groff" 
  operation="exec" name="/usr/bin/soelim" comm="groff" 
  operation="exec" name="/usr/bin/tbl" comm="groff" 
  operation="exec" name="/usr/bin/troff" comm="groff" 

All listed binaries somehow belong to groff (according to a quick look at their
manpage), so that's fine and means to add the following rules to the profile:

  /usr/bin/eqn mrix,
  /usr/bin/grotty mrix,
  /usr/bin/id mrix,
  /usr/bin/pic mrix,
  /usr/bin/soelim mrix,
  /usr/bin/tbl mrix,
  /usr/bin/troff mrix,

and of course also the two rules from my previous comment:

  capability dac_override,
  capability dac_read_search,

The attached profile contains these additions. Please replace
/etc/apparmor.d/usr.bin.lessopen.sh with this and run "rcapparmor reload"
afterwards. (The profile is in enforce mode, and I intentionally didn't add the
network permissions and the things noted below yet, so you might need to use
aa-complain again.)

You might also want to run
    old /var/log/audit/audit.log
    rcauditd restart
to start with an empty audit.log.



Now the interesting[tm] questions start:

... operation="exec" profile="/usr/bin/lessopen.sh" name="/usr/bin/id"
pid=32146 comm="lessopen.sh" requested_mask="x" denied_mask="x" fsuid=223
ouid=0

so lessopen.sh wants to execute "id" - but I don't see any "id" call in my
Tumbleweed lessopen.sh. Do you have a different lessopen.sh, or am I just
blind? (Allowing to run "id" doesn't look like a serious security issue
(especially because the profile already allows reading everything including
/proc/self/status) - but of course it should only be allowed if it's really
needed.)


And finally, there is (before you switched the profile into complain mode):

type=AVC msg=audit(1509081678.576:3010): apparmor="DENIED" operation="unlink"
profile="/usr/bin/lessopen.sh" name="/usr/bin/lessopen.sh" pid=30470 comm="rm"
requested_mask="d" denied_mask="d" fsuid=0 ouid=0

So for some reason lessopen.sh tried to delete itsself (by calling "rm") this
morning :-/  The exact time is:
  # date -d @1509081678  # the number after msg=audit is the unix timestamp
  Fr 27. Okt 07:21:18 CEST 2017

Any idea which of the "rm" commands in lessopen.sh did this? Checking your
(root) bash history for that timestamp might should which file you wanted to
view at that time, and that might make debugging easier.


(In reply to Dr. Werner Fink from comment #9)
> with
> 
>   network inet dgram,
>   network inet stream,
>   network unix dgram,
>   network unix stream,
> 
> the file command returns the corect identifier in both user abd toot case

The two "network unix" streams are only needed until AppArmor 2.11.1 reaches
Tumbleweed - there was a a bugfix in apparmor_parser which only showed up in
combination with kernel 4.14 rc2 and newer. (Dominique just accepted the
staging project, so it should be in one of the next snapshots.)

The two "network inet" rules are probably related to NFS - I'm still waiting
for an answer from upstream.