Comment # 16 on bug 1065388 from
(In reply to Christian Boltz from comment #14)
> 
> ... 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.)
> 

This id call was added for debugging only as I've checked out which which id
for lessopen.sh is used if less is used by root

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

Bug in my test code, fixed

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