http://bugzilla.opensuse.org/show_bug.cgi?id=1065388 http://bugzilla.opensuse.org/show_bug.cgi?id=1065388#c14 --- Comment #14 from Christian Boltz <suse-beta@cboltz.de> --- Created attachment 746220 --> http://bugzilla.opensuse.org/attachment.cgi?id=746220&action=edit 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. -- You are receiving this mail because: You are on the CC list for the bug.